STM32F4 Discovery ''No Target Connected'' Error, After 6 month using

[sherlock]

Posted on November 08, 2012 at 04:14

i've used stm32f4discovery boards for over 6 month in my IMU Projects. it works fine during that time.

And suddenly It shows error ''No Target Connected'' when i tried to program the chip (via debug) like as always. The keil recognized the STlink but it read no target connected. All Jumper fine, and no broken PCB trace in swd connection between STlink and the microcontrollers. My boards is ''A'' silicon revision, so i'm sure it has nothing to do with ''Z revision Problem''.What should i do? i'm struggling for over 1 month to solve this issue. Thx, any repplies will be very appreciated. :D

[Tesla DeLorean]

Posted on November 08, 2012 at 05:32

Try pulling BOOT0 High, and reconnecting, and see if device is recognized when it runs the System Loader code instead of yours. If you are able to erase the code, you are likely doing something in your code that is interfering with the SWD interface (ie DMA, JTAG/SWD GPIO pin changes, WFI loops).

Check the supply/regulator voltages. Did you change anything on the PC, or with the downloaded code, that correlates with the time it started to fail?

[sherlock]

Posted on November 08, 2012 at 06:01

Ok i will try your suggestion, I'm happy to see your replies seems there is a hope :D

Before this accident happen, i try to make some change on PIN function, at that time i also think i might interfering the SWD interface, but i lack of experience with this MCU. so i don't know what to do. after double check the code i'm pretty sure that i'm not change anything related to SWD. . . I will post any development regarding this issue. Thx Clive :D

[sherlock]

Posted on November 08, 2012 at 06:40

Thx Clive1 You save my money 🙂

I erased the main flash chip, reconect and finish. Next step is to check what the hell is wrong with my code. . .

[Tesla DeLorean]

Posted on November 08, 2012 at 08:00

Excellent.

It's usually something that occurs in first 10,000-100,000 cycles as the debugger tries to wrestle control, and then start things over. You could use a button to dump you into a while(1); loop to escape the processor at startup. ie you press the button and it loops rather than going to your main line code. Not that the BOOT0 trick isn't easy to do with some micro-gripper probes. I think I broke my first one doing DMA into a TIM/PWM, so DMA (activity external to the core, and hard to suppress), tight WFI/WFE loops, and of course remapping or miss configuring the GPIO pins associated with JTAG/SWD connections. They may be other triggers for breaking the ST-LINK connectivity, but it should be reasonably early in the code. Describe what you're doing or post code snippets if you need help.

[sherlock]

Posted on November 08, 2012 at 10:46

I Found it,

and this mistake make me embarrassed  like hell hehe, After all of this month it happen just because of this:+ I tried to access LIS344 SPI on Discovery board , to select its SCK - MISO and MOSI, I  changed the AFR GPIO registers to chose SPI as its alternate function. So i wrote : GPIOA->AFR[1] |= (uint32_t)0x55500000;In GPIO init . . .for god shake, i forgot that AFR[1] is the high one, not the low one (I should have write AFR[0]). in that chase it changed PIN A15-14-13 to chose Alternate fuction number 5 which was change SWDIO and SWCLK to SPI (that doesn't exist to them)Thx for your support Clive1, you are the best here i see, Thx :D