Resetting Non Processor Register on STM32F4

[johnsotack9]

Posted on January 31, 2013 at 21:24

I have an application that runs fine alone when booted stand alone but appears to have timing problems when branched to through a boot loader.  It appears to run slowing and I suspect timing related registers.

Is there a way I can reset all HW registers (including system clock) early in my application's reset handler.  My goal is for the application to behave as though it were booted stand alone rather than branched to through a boot loader.  My application of course has HW initialization code that includes clock setup code that normally works fine. #soft-reset

[Tesla DeLorean]

Posted on January 31, 2013 at 21:40

No, You'll need to walk back the settings you've done.

Alternatively you can put a signature in RAM that is recognized by the boot loader that causes it to jump directly into the application when you generate a reset. Why don't you dump out the registers and compare/contrast what's different between the failing and working states? There is typically a whole lot of code in SystemInit() that blindly assumes initial register conditions rather than work with what's in there. I've seen a whole lot of bad user code that makes similar assumptions.

[Tesla DeLorean]

Posted on January 31, 2013 at 21:57

Here's how one might get into the Boot ROM (System Loader), an app could be called in a similar fashion.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/DispForm.aspx?ID=7024&RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/STM32%20Internal%20Bootloader

Or a more generic application solution [DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Help%20with%20application%20jump%20to%20system%20memory%20boot&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=393]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FHelp%20with%20application%20jump%20to%20system%20memory%20boot&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=393

[johnsotack9]

Posted on January 31, 2013 at 23:23

Thanks.  I will need to digest these suggestions.

Right now what is odd is that if I run the boot loader from my debugger, things seem to work.  If, instead I take off the debugger and cycle the power, it mostly works except for some apparent timing issues.  For example, I can use my applications debug menu to flash a pattern on an LED meaning there is a general sense of time and UART communications are working. I like the RAM signature suggestion.  In that case I could probably watchdog, look at memory, and go directly to the application without altering any registers if the signature is the right magic number.  If that works I will still be puzzled as to why: 1.  The application runs correctly whether started by the dubugger or a power cycle when it is stand alone. 2.  The application runs correctly when started via the bootloader (right now all it does is the standard initialization and then branches to the application) if the bootloader is started by the debugger. 3.  The application runs with at least one noted problem (an RTOS free running timer does not appear to be doing its job.  More specifically, code that waits on a semaphor the timer handler sets does not seem to run. Having the application directly started after a WD reboot with eliminate the double register initialization.  However, it would not explain why things work when using the debugger. I will also likely try dumping the register values as you suggested.  The debug terminal should allow this. John

[Tesla DeLorean]

Posted on January 31, 2013 at 23:34

Debugger's do a lot of house keeping to permit themselves to do the job, always assume they are at least somewhat invasive.

Watch for any situations where a register is blindly written with no consideration to the current content. There is a lot of code in system_stm32f4xx.c which is sloppily written. You could completely remove the SystemInit() call in the boot loader, the system would remain in the initial 16 MHz HSI state.

[johnsotack9]

Posted on February 01, 2013 at 16:48

I think your solutions of immediately branching to the application based on a magic number in ram with work.  I did a quick test where I put assemble code to branch to the application immediately rather than after the system initialization and the issue disappeared.  If the boot loader has finished its job and it is time to run the app. I can then write the magic num and watchdog and theoretically it will be the same as booting to the app directly.

John