STM32f429I crashes when activating TIM8

[smrtkai]

Posted on April 20, 2016 at 17:53

Hi,

I am using a STM32F429I discovery board and I would like to use the TIM8 with external clock source to trigger ADC conversions. Unfortunately, when I activate and configure TIM8 in STM32CubeMX my application crashes completely (e.g. other timers do not output anything anymore). If I comment out ''MX_TIM8_Init();'' everything works as expected. If  ''MX_TIM8_Init();'' is called, the application seems to crash while sending the SDRAM initialization sequence. What can possibly go wrong? And where can I find more information about a possible crash? I am using Keil uVision as IDE. Basically the application outputs some signals with several timers, reads resulting values using the ADC and displays the results on the display. I have ported the configuration for SDRAM and LCD to STM32CubeMX from the board support package, used in the examples.

[smrtkai]

Posted on April 20, 2016 at 17:58

The application tries to execute ''HAL_SDRAM_SendCommand(&hsdram2, ..)'' to configure the clock configuration. When debugging, Keil exits with ''Debugger - Cortex-M Error - Cannot access target. Shutting down debug session.''.

[Tesla DeLorean]

Posted on April 20, 2016 at 19:06

Make sure it is not involving any SWD/JTAG pins, clocks, etc. Or placing the part into a low power mode.

[smrtkai]

Posted on April 21, 2016 at 12:01

Okay thanks. Where do I find this information?

In User Manual UM1670, I have found STM32F429I-DISCO's pin configuration for SWD and USB (Chapter 4.13 Extension connectors). But I do not use the external SWD pins and I suppose that the USB pin configuration is the user USB port and not the ST-Link-USB port. I haven't found anything about JTAG.I cannot see any pin collision with external SWD or external USB in my configuration. I have not found where the internal ST-Link pin configuration is documented. There might be a collision.It seems, that there are two problems. First a problem with debugging and second a problem with the SDRAM. I have also checked for pin collisions with the SDRAM. But there are none.Do you have any further suggestions?

[Tesla DeLorean]

Posted on April 21, 2016 at 18:52

Where do I find this information?

You're going to have to dig into your source code, library included, and look for things which are likely to break the interface. The debugger typically does not detach unless you break the pins it is using, or remove power from the chip.

[smrtkai]

Posted on April 22, 2016 at 09:02

Sure, I am looking into my source code. I meant, where do I find more information about the debug interface?

[Tesla DeLorean]

Posted on April 22, 2016 at 20:03

The Data Manual describes the pin utilization, PA13 SWDIO and  PA14 SWCLK at a minimum for the SWD interface. You can do things with the GPIO Bank which will break and disconnect these. If you remove power, nothing internal is going to work, including the debug interface, ie a sleeping WFI.

If you are looking at the code, you should be able to step to exactly the point the interface drops, but so far you've mention one higher level function.

[smrtkai]

Posted on April 25, 2016 at 09:26

Okay, I have already checked that. All pins for SWD are unused. When stepping through the code, Keil complains with ''Cannot access target.'' It breaks when executing the following command.

 

/* Set command register */

  tmpr = (uint32_t)((Command->CommandMode)                  |\                    (Command->CommandTarget)                |\                    (((Command->AutoRefreshNumber)-1U) << 5U) |\                    ((Command->ModeRegisterDefinition) << 9U)                    );      Device->SDCMR = tmpr;Which is called from HAL_SDRAM_SendCommand() in my initialization for the SDRAM.  If I deactivate the timer initialization debugging does not break. I have no clue, what I am doing wrong and where to look.

[Tesla DeLorean]

Posted on April 25, 2016 at 15:46

Ok, is it possible that you have some external connectivity or interaction, that could cause the supplies to brown out, or the device reset?

Suggest you use a scope/analyzer, and trigger on NRST, see if that drives low, or the supplies drop. Look also a what SWDIO/SWCLK are doing. Consider packaging your project in a way you could submit to to ST developers for review.

[smrtkai]

Posted on June 17, 2016 at 10:12

So, that was a strange error and it took quite some time to solve it. It had nothing to with any timer at all.

I had the LTDC configured with layers in STM32CubeMX. The BaseAdress of the layers were set to memory on the SDRAM. But the SDRAM was not initialised when the layers were configured in HAL_LTDC_ConfigLayer which is invoked by MX_LTDC_Init.I have deleted the layer configuration from STM32CubeMX and configured the layers somewhere ''later'' in my code; after sdram initialization. And finally everything works as expected.