[STM32F205RG] MCU seems to lock itself.

[root]

Posted on July 13, 2011 at 13:47

Here is the full story ...

I re-designed an existing product which was based on a PIC24HJ128GP202 (16 bit, 40 MIPS from Microchip).

The new version uses an STM32F205RG (TQFP64).

Physically, all JTAG + RST signals are available on the JTAG connector as in the ST Link documentation ( 

http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/USER_MANUAL/CD00221563.pdf

 ).

I use an ST Link V1 probe with latest firmware (J12).

First I tried Atollic TRUEStudio PRO (eval), everything worked for 1 or 2 days then their stlinkgdbserver.exe kept crashing each time I started a debug session.

I could connect to the MCU via ST link utility, but when trying to ''run'' from the core panel, each time got an error message ''unable to run application''.

I changed the MCU (desoldered / resoldered another one), and switched to TASKING VX-Toolset for ARM v3.1R2 (eval too).

Everything went good for 2 days, developped some features based on USARTs and TIMs (OC/IC), and yesterday, started to get error message when starting a debug session.

Today, plugged everything, and impossible to start a debug session (unknow ST Link error). Using ST Link utility, the logs says it can connects with JTAG but the MCU is not responding.

The program is running (LED is switched on), but it seems I cannot talk to the MCU.

I changed the MCU again (even changed the whole board, soldered a new one), first no problem using STLink utility, can connect, read flash, etc. Then downloaded the HEX file and the MCU disconnected (running the program ...).

My only guess is the MCU is entering read out protection level 2 (thus disconnecting the JTAG port) ... but nowhere in my code I intent to do this !

I'm really on a hurry for dev, and I already lost almost a week on this (first with Atollic, now with TASKING). TASKING support is searching.

I really need help. I already ''fried'' 4 MCUs, and they'r not cheap ... but I mainly loose precious time.

Is there something I can do to check the MCU has entered ROP level 2 (it's irreversible ...)?

Is there a incompatibility between ST Link and the STM32F205RG chip?

Why the hell is it working 2 days then suddenly it stops?????

I mean if it was a design flaw in the board, it would just now work at all... 

Is there a bug somewhere? In the MCU? In the STLink?

Is someone working with this chip (STM32F205RG in TQFP64 package) for more than a week? With which probe and toolset?

Regards,

Thomas Legrand.

[Tesla DeLorean]

Posted on July 13, 2011 at 14:25

The STLink has general problems breaking a CPU out of an interrupt storm. At reset it has to regain control from the code that is running, it can run several thousand instructions before it does this, and if you foul things up in the system, or lockout the JTAG, you won't get access.

Try changing the BOOT pins so it runs the system loader, and not your broken code. You could also try using the system loader via the USART to update the firmware, rather than JTAG, but this requires some forethought in the board design to be accessible. You might also consider more commercial/professional JTAG solutions like the Segger J-Link, or Keil U-Link, depending on your IDE. Even if you have ROP enabled the STM32F1 series was recoverable via the serial port, I wouldn't suspect the STM32F2 would be that different, so unsoldering parts seems to be overkill. Consider adding a button/GPIO test in the very front of your code, so that the processor can go to a safe place after reset, and you can gain control via JTAG. Consider a serial port debug console that would permit breaking the normal execution, and provide telemetry in the running/failing system.

[root]

Posted on July 13, 2011 at 15:03

Hello,

Thanks a lot for the reply.

I fact the board is designed to get access to the integrated bootloader too. I have access to the BOOT0 pin via a button and full access to USART1.

I can enter the bootloader mode when keeping the BOOT0 btn down will I press the RESET btn (the LED is not turned on).

I tried to do something with ''flash loader demo'', I can go to the second step, but then I have no target options, and can't do anything (tells me the MCU is locked, or the command is not supported on the target). I'd need a tool that supports the STM32F2xx chips !

If I try STLink utility or TASKING when in bootloader, it seems the stlink first reset th ........  WOUHOU !!! I unlocked it, I kept the BOOT0 button pressed all the time and the ST-Link utility managed to get control back !!!!!

I did not take a decision yet on the toolset (that's why I tried atollic and TASKING), the only real requirement is an eclipse based IDE. I can buy a new probe if the ST Link is not suitable.

Now that it is unlocked, I need to know why I have such an ''interrupt strom''???

Any hint?

Interrupt wise, I only use TIMs and USARTs...

Best regards,

Thomas Legrand.

PS : thanks a LOT !

[root]

Posted on July 13, 2011 at 15:27

Ok I think I found it ...

my main was like :

Init();

while(1)

  __WFI();

I changed back to :

Init();

while(1);

and now I can keep control over the MCU ...

Is this a known issue?

Best regards,

Thomas Legrand.

[Tesla DeLorean]

Posted on July 13, 2011 at 17:58

An interrupt storm is basically where the Cortex-M3 is stuck in an interrupt servicing loop (tail-chaining) when the pending interrupt isn't cleared, and it keeps looping. It's probably one of a number of things that would prevent the processor from running code injected by the JTAG pod. WFI might be another, the JTAG pod would probably need to generate an interrupt to break the halt.

Basically at reset the JTAG is trying to inject it's own code and wrestle control from the code running in the processor, given the nature of the JTAG signalling this might take several thousand (tens or hundreds of thousands perhaps) cycles to get the CPU into a state where it can run your code in a controlled fashion. Most pods have several methods to reset/wrestle the processor, some work better than others. I bricked a VL Discovery board (STM32F100 + STLINK) with some code I loaded on it, it might have had a WFI, I don't recall, I was using a TIM to measure frequency. Are you sure you need Eclipse? If the slowness of Atollic is anything to go by and the awkwardness of the project directory structure/workspace, I'd be running in the other direction. I'm not sure if there is a current version of the flash loader that works with the STM32F2 series, it does come with source, and the protocol is documented. I wrote my own version for production programming, but haven't played with the STM32F2 series to this point.