STM32F429ZI Keil v5 and STLink Debugger Access Corrupting While Debugging

[Kasapoglu.Orkun]

Posted on April 06, 2017 at 15:27The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on April 06, 2017 at 17:45

Classic reasons for disconnection are resets, low power modes and _WFI, also reprogramming the GPIOA pins the SWDIO/SWCLK reside on.

[Kasapoglu.Orkun]

Posted on April 07, 2017 at 17:36

Thanks

Turvey.Clive.002

‌. I've found something about that or not I don't know can you take a look at the updated question?

[Tesla DeLorean]

Posted on April 07, 2017 at 17:55

I'd remove 

SDRAM_GPIOInit(); from the loop, doing it 3 times is problematic. Do it once and early.

I'll try and walk the code some more later. The GPIO Init stuff looks good as I scan through it. Consider initializing FMC for both THEN SDRAM for both rather than FMC+SDRAM twice.

If you just enable one bank, do both work independently.

[Kasapoglu.Orkun]

Posted on April 10, 2017 at 09:54

Thanks

Turvey.Clive.002

‌. I added the SDRAM_GPIOInit(); in loop because of the Discovery kit's example. In this example, first callingGPIO configuration function then initializes the FMC andSDRAM then calling again GPIO configuration. Maybe wrong but I thought there could be a trick. Anyway, I did what you said, I've moved the SDRAM_InitSequence(); out of the loop then removetheSDRAM_GPIOInit(); linefrom the loop. Now I am not getting the debug access failure but HardFault_Handler(); occurs when I try to write to SDRAM with *(__IO uint8_t *)(SDRAM_BANK2_ADDR + counter) = 0x00; SDRAM_BANK2_ADDR = 0xD0000000 and counter is starting from 0x00end with0x4000000 - 1.

EDIT: It's my fault there is no hard fault Iwasn't disabling the write protection. But the situation didn't changed with changing the initialization sequence.