Debugging STM32F0 app

Discuss how to use the features of Atollic TrueSTUDIO, including the editor, assembler, C/C++ compiler, linker, debugger, static code analysis and team collaboration tools.

Moderators: Markus Girdland, Mattias Norlander

dwighttovey
Posts: 2
Joined: Tue Feb 26, 2019 6:39 pm

Debugging STM32F0 app

Postby dwighttovey » Wed May 22, 2019 5:37 pm

Hello all -

I'm developing an application for an STM32F030K6 and I'm running into a problem with the debugger when I jump to the main app.

Up until yesterday my program was a single monolithic program and I haven't had any major problems with the debugger. However in order to support IAP yesterday I split the program into a bootloader and the main app following the multiple examples that I have found here and elsewhere on the internet. The main app is stored in Flash at addr 0x8002000.

The bootloader will come up, initialize the hardware, then listen on the SPI bus for some simple commands (current status, download new code, jump to main). When it receives the command to jump to main it will load the stack address and the app start address from the vector table stored at 0x8002000, sets the stack pointer and jumps to the app:

Code: Select all

while( 1 )
{
  ... process SPI commands ...

  if( g_goAppMain )
  {
    __disable_irq();
    uint32_t startAddr = FLASH_BASE + 0x2000;
    uint32_t appStack = (uint32_t) *(volatile uint32_t *)startAddr;
    pAppFunc appEntry = (pAppFunc) *(volatile uint32_t *)(startAddr + 4);

    __set_MSP( appStack );
    appEntry();
  }
}


If I bring up the bootloader in the debugger, everything is fine.

My app so far just copies the vector table into ram, remaps RAM to 0x00000000, turns on a single LED, then goes into a while loop:

Code: Select all

volatile uint32_t VectorTable[48] __attribute__((section(".RAMVectorTable")));
int main()
{
  uint32_t idx;
  for( idx = 0; idx < 48; idx++ )
  {
    VectorTable[idx] = *(volatile uint32_t *)((FLASH_BASE + 0x2000) + (idx << 2));
  }
  MODIFY_REG( SYSCFG->CFGR1, SYSCFG_CFGR1_MEM_MODE, SYSCFG_CFGR1_MEM_MODE_0 | SYSCFG_CFGR1_MEM_MODE_1 );

  setLED( LED_ID1, LEDON );
  while( 1 ) { }
}


If I try to run the debugger on the main app, I run into problems. The debugger will start OK, and since the MCU was reset as part of the debugger startup, the bootloader is running. I can set a breakpoint anywhere in the main app that I want (including at the entry to main or in the setLED function), and when I issue the SPI command to jump to main, the MCU will launch the main app and the breakpoint will trigger correctly, and I can examine variables correctly. However if I try to continue execution, single step, or stepi, I somehow end up back in the bootloader. Using stepi I can see the PC going from 0x80021e0 (for example) to 0x8000dd2 which is back in the bootloader at the top of the while loop.

I am using Atollic TrueStudio Version 9.3.0 on a Linux system using an ST-Link to connect to my application board.

I'm probably missing something basic in my debugger setup, but I'm kind of lost as to what it is. Any help would be greatly appreciated.

/dwight

dwighttovey
Posts: 2
Joined: Tue Feb 26, 2019 6:39 pm

Re: Debugging STM32F0 app

Postby dwighttovey » Fri May 24, 2019 10:39 pm

Ok, never mind. I was being an idiot. Because of the breakpoint and halting the system, my device (which is a SPI Slave) was not sending back a proper response to the SPI Master for the jump to main command. The Master would then time out and pull the reset line low in an attempt to recover the Slave. That's why as soon as I tried to single-step my device I would find myself back in bootloader space. Once I took control of the Master so that it doesn't try to reset, everything is good.

That's what I get for not watching ALL of the lines on the bus during development.
/dwight


Return to “Atollic TrueSTUDIO tool discussions”

Who is online

Users browsing this forum: MSN [Bot] and 4 guests