VisualDSP ADI driver for external flash stalls kernel?

jr536 Question

Oct 29, 2015 00:00

Hi

I'm a newcomer to VisualDSP & Blackfin having inherited a development from an engineer who left.

I've got a BF536 processor connected to a M29W320 flash chip.

My problem is that when I erase a sector of the flash the ADI driver (Program files\Analog Devices\VisualDSP 5.0\Blackfin\lib\src\drivers\flash\adi_m29w320.c)) sits and waits for the flash chip to say it's ready before it will return. This takes (from the datasheet) typically 0.8s to a max of 6 seconds.

I also have to toggle an output pin to keep an external watchdog alive. This must happen within typically 1.6s (0.9 min - 2.5 max, from a tps3823)

The running tasks (watchdog & heartbeat are the most visible/obvious ones) stall when I'm erasing a sector of the flash chip, if this lasts too long then I'll get watchdog timeout.

At the minute it's working fine without timing out, but the timing variations mean this isn't safe.

Any good ideas, anyone?

Thanks in advance

JohnR

Report

PrasanthR Reply

Nov 30, 2015 00:00

Have you tried modifying the driver code, to return without checking and verify it later, perhaps after approx 6 seconds. I am assuming you don't want to timeout your flash operation, but the watchdog is supposed to do it for other tasks.

You could also perhaps return from driver and set a variable. In the timer interrupt (I am supposing you have some timer for the GPIOs) check the variable. If it is set, poll after more than 7 times that you have toggled the GPIO. If poll is still bad, stop GPIO as you wish to.

Report

jr536 Reply

Dec 3, 2015 00:00

Thanks for that. It's probably the best way to go, but might involve a lot of work to integrate it with the rest of the code (which I don't really know yet) & the ADI VDK.

For the moment I've put a call from inside the tight loop that checks for 'ready' to a routine (located in a board customisation file since this will run on several hardware solutions/platforms) that just toggles my watchdog output pin every <n> calls. By adjusting the value of <n> I can get an output that's close to the normal running waveform for this pin. It's quick & dirty, but it keeps the development progressing for now.

Report

EZAdministrator Reply

Aug 2, 2018 00:00

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin

Report