STM32L151 code that only runs correctly from an SWD/IDE reset and run

[julian239955_stm1]

Posted on June 15, 2015 at 08:37

Hey there,

I'm having interesting times with an STM32L151 programming via a nucleo board's integrated SWD debugger (from CooCox ide..... using arm mbed platform too if that helps..) 

I'm in the interesting position where I've imported some code into my project (initially from an 8051 based project - to setup and configure an Si4463 radio chip) and what happens is, if I use SWD debugger to reset the chip then run the code, it works great... BUT.. if the processor is power cycled, hard reset using the reset pin, or even clobbers itself with the watchdog timer and restarts, then this imported code no longer works right... (the application still runs, just the SPI connected radio IC doesn't get setup right..) 

Never seen anything like this before - and until today I'd assume SWD reset and run should be the same as a power up or hard reset or watchdog reset... but it's obviously not.. Can anyone explain the differences at the chip level for me? I'm hoping to be able to get this code running right for any reset type, without too much more pulled out hair..

thanks!

#swd #stm32l151

[Tesla DeLorean]

Posted on June 15, 2015 at 12:22

Make sure you enable all the peripheral clocks you need, don't rely on the side-effects of the debugger enabling things it needs to function.

Check is there is anything timing critical, the debugger may distort the speed at which things run.

[julian239955_stm1]

Posted on June 15, 2015 at 14:47

Interestingly enough, I was looking a the chip datasheet and it claims to require a 10us pulse on the SHDN pin to do a full reset, and my code was only doing about 1us... but when I added in a delay after asserting SHDN to increase that, it broke the code for all launch types...

Is it really possible that peripherals like timers could end up set differently depending on reset method? if that's the case, I'm calling bug. major bug.

As far as I understand, using the debugger it runs the startup code first, then just halts at the first instruction relating to the beginning of main() where it waits to be launched by the user pressing the run button... So all I can think of right now is to put a nice delay in the very start of main() and see what happens... though feel like it's grasping at straws...

[Tesla DeLorean]

Posted on June 15, 2015 at 15:06

Debugger's are invasive. It's like a kids bike with training wheels, it doesn't drive/turn the same. The real test is whether you can stay upright when they are removed.

If the system doesn't function properly out of a cold reset it's because there's something intrinsically wrong with your code. Either the way it initializes the clocks, or does timing/time-out loops.

CooCox breaks the normal CMSIS initialization model, you'd want to watch that.

On a hardware level be concerned with BOOTx pin state at reset, and how, and for how long, NRST is driven low.

[julian239955_stm1]

Posted on June 15, 2015 at 22:44

aaaaah great... OK, thanks for the warning and the pointers.

Very disappointing, as I don't see why a well designed debug peripheral couldn't just set a breakpoint and halt the core right at the beginning of main, like it gives the impression it's doing... I understand OCD is never going to be as good as a full blown in circuit emulator, but have really seen very little in the way of side effects up until now (though I have been using JTAG this is my first SWD device I've tried using - but SWD just seems to be JTAG over some I2C-alike transport...) 

Part of the issue is this whole mbed framework is a giant pile of abstraction, so quite hard to work out what the actual register settings for anything even are by looking at the code....

So... any suggestions as to where I should be bothering people? mbed? ST reps?

[Tesla DeLorean]

Posted on June 16, 2015 at 00:45

So... any suggestions as to where I should be bothering people? mbed? ST reps?

ST doesn't participate here very often, and I'm pretty self sufficient. You could push back through the channel to distribution or ST FAE's

It's reasonably easy to nuke the mbed stuff out of the Nucleo board. The presence of the USART2 PA2/PA3 as a Virtual COM Port, and the SWV via the SWO pin, do permit progress inside the board to be tracked without and with the debugger active.

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/USART%20Problem%20with%20nucleo%20L152&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=176

[julian239955_stm1]

Posted on June 16, 2015 at 04:15

Thanks!

I wonder if it's also useful to try porting the project to a different IDE? assume atollic or codevision should do the same job with a more standard debug interface? 

Anyway - for general viewing pleasure, here's a picture of what's happening.. Top picture is the good working operation on a debugger launch.. bottom is any other kind of launch... 

yellow = CLK, green = nSEL, blue = MOSI, purple = SHutDowN signal... 

So it's not so much the spi config that's mangled but the actual data and order of what is happening?? really weird. 

What's also funny is the programming code actually claims that either of these things have programmed the chip successfully... 

[julian239955_stm1]

Posted on June 16, 2015 at 04:43

I was also interested in removing the usage of MBED for the SPI peripheral I'm using. only issue is I need it for the (properly working every time) library I'm also using for another different radio IC... I wonder how the mbed framework handles me using one peripheral their way, and another directly?