Flash writing problems

[hli]

Posted on October 07, 2010 at 21:14

Flash writing problems

#dfu

[Tesla DeLorean]

Posted on May 17, 2011 at 14:10

Well if you are not accessing the memory in an aligned fashion you will get a HardFault, if you access an illegal address it will also HardFault.

If you don't service interrupts and clear them you will be stuck endlessly in the interrupt context. Try single stepping the offending code, it should be pretty obvious where it goes when it gets stuck.

[hli]

Posted on May 17, 2011 at 14:10

Hello,

I understand your suggestion but I think  (I am not sure of it ; maybe you could say I am wrong), that I could not enter debug mode with the software with the DFU switching code already installed. To summarize the operation principle, my product do this :     - wakeup from standby     - enter DFU ''switching'' code          a) if DFU conditions are fullfilled, enter in DFU mode          b) if these conditions are not present, enter in normal mode     - perform some information exchange     - make flash access (for the time being, it never succeed this)     - enter standby mode So based on your comments, I will add some operations in the interrupt management code at least to understand where the unit is stuck. But I am not sure, it will give me the information about the deep reason of my errors. Do you think the shift of the DFU code (which is a multiple of memory page) could induce a problem in the standard code ? Regards,

[damh]

Posted on May 17, 2011 at 14:10

Single stepping isn't a realy good idea per se in this case, especially if you write to the flash!

If your debugger does something with the flash, before the flash says that it is ready, the flash is in most cases unusable until reset. If you want to set and use breakpoints, do it after controlling the ready-signal of the flash! In any other case you will get curious behavior.

[Tesla DeLorean]

Posted on May 17, 2011 at 14:10

Well it might at least get you to the code, determining if hardware register values and cpu registers/addresses are what you expect and get some understanding of the flow, even at a gross level.

The other suggestions would be to test the code separate from the current app, and verify that works. Use the UART for debug output and instrument the the code. Instrument the fault vectors with messages or LEDs to understand if you end up there. Instrument loops where you might get stuck expecting status changes.

[hli]

Posted on May 17, 2011 at 14:10

Hi,

A short summary first : I have a DFU ''switch'' programmed in my uC. My application is programmed at 0x08003000 address. Everything is working properly (reading from flash also) if I do not erase or write in Flash. As soon as I try to erase/write, my application is blocked. This application perfectly works if there is no DFU switch and if it is located at 0x0800000. Therefore, I assume that the problem is linked to the memory shift I have to use for the DFU switch but I really do not understand why. I also would like to know if in my own application (after DFU switch) there is any heritage from the DFU code (flags, config, ...) which could not allow memory writing. Best regards, Hugues

[Tesla DeLorean]

Posted on May 17, 2011 at 14:10

Interrupts, Vector Table? PC sensitive code? Try dumping out peripheral and system registers. Or try adding some boot code at 0x08000000 that runs your code situated at 0x08003000

If you'd instrumented your code 6 weeks ago, and walked through the code, you might have a better idea where things are going awry and why.