STM32F105RB problem

[gomez_2611]

Posted on May 30, 2014 at 15:57

Hi,

I am facing a problem with the MCU model STM32F105RB. I am using it with the J-link EDU.

I use a custom hardware, which works properly with the STM32F205RB model. Now I am trying to use the same custom hardware with the model STM32F105RB, adding the two resistors as stated in the datasheet (see next figure).

https://dl.dropboxusercontent.com/u/60356745/resistors.PNG

The problem is that when communicating with the MCU via the J-Link Commander, I am getting this error:

https://dl.dropboxusercontent.com/u/60356745/commander.PNG

I have also read in the segger forum that to unlock the MCU it is also necessary to use first the J-Link STM32 Unlock, but it trhows the following error.

https://dl.dropboxusercontent.com/u/60356745/unlock.PNG

Thanks in advance

j-link-jtag-st-link

[Tesla DeLorean]

Posted on May 30, 2014 at 16:39

Without wading through the docs, I'm going to assume those are the VCAP pins.

You should check all the supply pins for the correct voltages. Including the analogue supplies. You should check the NRST pin state. You should double check the part pin 1 orientation, and the soldering

[gomez_2611]

Posted on May 31, 2014 at 11:00

Thanks for reply. I have checked this, but i get the same result. I have also changed the MCU for a new one, so nothing has changed. Any suggestion?

Thanks

[Tesla DeLorean]

Posted on May 31, 2014 at 17:15

If this were my board I'd be reviewing the schematic, but I have a very narrow view into your design.

The JTAG/SWD can fail to work if the core is not power, enters a shutdown/low power state, is held in reset, or the connections are just not there. Incorrect orientation seems to be a frequent issue here. As does odd reset circuits driven high or low with push-pull drivers. Wrong supplies. Absent analogue supplies which control the power-on-reset circuit. You could pull BOOT0 high, and attempt connection via USART1 or USB. The System Loader should be responsive at 9600 8E1, send an 0x7F byte and see if you get an 0x79 response. This is one of the other alternate signs of life methods, but again if the core isn't running, all bets are off.