Skip to main content
Manu Abraham
Manu Abraham
Senior
April 8, 2017
Solved

stm32f334 and probably a stack overflow.. ?

  • April 8, 2017
  • 2 replies
  • 3865 views
Posted on April 08, 2017 at 15:31

Hi,

Have been doing quite a bit of drawing onto a LCD display with SPI and DMA. In the process of updating the display, i found the results were unexpected, but the code doesnt seem to be the culprit, since when I test individual parts of the code things do appear working as expected. Eventually, printing it out, my favourite debug model, putstr(), putting a string to the UART Tx register also appear to have frozen (attached screenshot), in all probability.

The program still fits into the flash .. :) The controller is a STM32F334R8T6 (LQFP64)

*** Using Compiler 'V5.06 update 4 (build 422)', folder: 'C:\Keil_v5\ARM\ARMCC\Bin'

Rebuild target 'Target 1'

assembling startup_stm32f334x8.s...

compiling stm32f30x_gpio.c...

compiling stm32f30x_adc.c...

compiling stm32f30x_rcc.c...

compiling stm32f30x_i2c.c...

compiling stm32f30x_usart.c...

compiling stm32f30x_misc.c...

compiling stm32f30x_spi.c...

compiling stm32f30x_dma.c...

compiling stm32f30x_hrtim.c...

compiling stm32f30x_tim.c...

compiling stm32f30x_syscfg.c...

compiling stm32f30x_rtc.c...

compiling pwm.c...

compiling uart.c...

compiling adc.c...

compiling misc.c...

compiling dma.c...

compiling lcd_ili9341.c...

compiling spi.c...

compiling rbuf.c...

compiling plot.c...

compiling mav.c...

compiling font.c...

compiling clock_ana.c...

compiling main.c...

compiling clock_dig.c...

compiling rtc.c...

compiling graphics.c...

compiling thermo.c...

compiling rc5.c...

compiling timer.c...

compiling menu.c...

compiling seg7.c...

linking...

Program Size: Code=23722 RO-data=11158 RW-data=372 ZI-data=5508  

FromELF: creating hex file...

'.\Objects\Test 2.axf' - 0 Error(s), 0 Warning(s).

Build Time Elapsed:  00:00:24

Originally, I've had the

Stack_Size      EQU     0x00000400

thinking that the stack size (1024 bytes) could be a problem,  increased it to (4096 bytes)

(attached startup code), but the change did not make any difference.

One question that I have, the RO-data, is it in RAM or Flash ? If it is RAM, the 12kb of SRAM is almost done .. :(

But I guess the RO-data is in ROM.

(The STM32F334 seems like a one of a kind microcontroller. Even the STM32H7 microcontroller which is previewing, seems to have a scaled down variant of the HRTIM peripheral. Sad that there aren't any other controllers from ST, having HR-PWM and larger memory/clock speeds. :( Maybe someone @ ST takes note of this issue and closes the gap hopefully. If you are asking for my wish, more PWM pins and ADC pins, DMA channels, definitely are nice goodies. The Infineon XMC chips seems nice with regards to memory and peripherals especially the HRPWM and the PID controller on it, but that would mean switching everything. The TI UCD3138xx seems to have everything, but that one doesnt seem to be pleasant to work with any way)

Getting back from my little rant, I am wondering how to dissect this problem. Can someone give me some insight how to navigate this issue ?

Thanks

    This topic has been closed for replies.
    Best answer by Tesla DeLorean
    Posted on April 08, 2017 at 20:01

    I use this in uV4

    https://community.st.com/0D50X00009XkeksSAB

    Adding more text to break moderation w/link

    The BKPT suggests it is calling printf()/putchar() via semi-hosting code in the library, you don't want that happening..

    2 replies

    Tesla DeLorean
    Tesla DeLorean
    Guru
    April 8, 2017
    Posted on April 08, 2017 at 18:02

    For stack I typically add code to check the depth in dynamic usage, also Keil outputs an HTML file breaking down the call tree and stack usage.

    The stack is placed immediately above the heap and statics, if it ploughs into them you can get odd behaviour.

    Make sure you properly initialize or clear auto/local variables.

    Use a proper Hard Fault Handler so you can see if any gross failure has occurred.

    https://community.st.com/0D50X00009XkYYDSA3

    https://community.st.com/0D50X00009XkfOXSAZ

    Use the debugger in this situation to understand where it is actually stuck.

    Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
    Manu Abraham
    Manu AbrahamAuthor
    Senior
    April 8, 2017
    Posted on April 08, 2017 at 19:12

    Hi Clive,

    I find the very first line in the html file, strongly indicating the function call depth.

    Maximum Stack Usage = 280 bytes + Unknown(Functions without stacksize, Cycles, Untraceable Function Pointers)

    I tried adding in

    void HardFault_Handler(unsigned int * hardfault_args, unsigned int r4, unsigned int r5, unsigned int r6)

    {

    printf ('[Hard Fault]\n'); // After Joseph Yiu

    printf ('r0 = %08X, r1 = %08X, r2 = %08X, r3 = %08X\n',

    hardfault_args[0], hardfault_args[1], hardfault_args[2], hardfault_args[3]);

    printf ('r4 = %08X, r5 = %08X, r6 = %08X, sp = %08X\n',

    r4, r5, r6, (unsigned int)&hardfault_args[8]);

    printf ('r12= %08X, lr = %08X, pc = %08X, psr= %08X\n',

    hardfault_args[4], hardfault_args[5], hardfault_args[6], hardfault_args[7]);

    printf ('bfar=%08X, cfsr=%08X, hfsr=%08X, dfsr=%08X, afsr=%08X\n',

    *((volatile unsigned int *)(0xE000ED38)),

    *((volatile unsigned int *)(0xE000ED28)),

    *((volatile unsigned int *)(0xE000ED2C)),

    *((volatile unsigned int *)(0xE000ED30)),

    *((volatile unsigned int *)(0xE000ED3C)) );

    while(1);

    }

    to main as you suggested in

    https://community.st.com/thread/15262?commentID=8095#comment-8095

    But that freezes up everything, stuck at SystemInit

    Attached screenshot

    variables are minimal, and all of them inittialized before use.

    How to use the debugger, when doing DMA transactions and such ? Also, steeping through delays seems like the steps do not end, even for those very small delays.

    ________________

    Attachments :

    Test 2.htm.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Hyih&d=%2Fa%2F0X0000000bBU%2F9q4YuSPLN_I_rdp0E0wKPgI3qSinE09mrGDrL7FG_G0&asPdf=false

    Stuck.PNG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HyiY&d=%2Fa%2F0X0000000bBW%2FNY0QR4bwbfymNfTPndQF15jmrxjGI_PQ7H7yelMzWGw&asPdf=false
    Tesla DeLorean
    Tesla DeLorean
    Guru
    April 8, 2017
    Posted on April 08, 2017 at 19:36

    You'd need code hosting the USART output. If it fails prior to main(), break-point the handler

    Not recommending single-stepping real-time code, but when it locks up you need to make a determination about where it is, and the general state of the system. Once you know where to start looking, add telemetry and diagnostic output, and recognize system conditions leading to the failure.

    Tips, Buy me a coffee, or three.. PayPal VenmoUp vote any posts that you find helpful, it shows what's working..
    S.Ma
    S.Ma
    Principal
    April 10, 2017
    Posted on April 10, 2017 at 11:12

    When merging different piece of code, check that all the interrupt handlers are present. You could toggle a GPIO when entering ISR and see if it is swamped in one because the ISR is not clearing any HW pending flags...

    Manu Abraham
    Manu AbrahamAuthor
    Senior
    April 12, 2017
    Posted on April 12, 2017 at 15:40

    Actually was not merging code at all, but trying hard to selectively paint the display regions. the calculations to do the offsets were long and giving me a headache, (such that only  the deltas are drawn, while I could resize the display) which made me dump those values to a console, to detect issues. But the issue turned out not to be there in those calculations or values, but somewhere so silly. The idea to toggle a GPIO to test ISR swamped is quite thoughtful.

    Terms & ConditionsAccessibility statement