cancel
Showing results for 
Search instead for 
Did you mean: 

Debugging issues with STM32CubeMX for STM32F100RCT MCU generated project in Atollic

_Anani Popov
Associate II
Posted on June 06, 2017 at 12:52

I am having issues when debugging STM32CubeMX for STM32F100RCT MCU generated project in Atollic. The ST-Link debugger jumps to unknown code location and generated HW fault exception. It happens with Cube generated peripheral INI HAL like TIM16, TIM17 and SPI1 as well. Usually in TIMx cases it happens when tmpcr1=TIMx->CR1; line in HAL {void TIM_Base_SetConfig(TIM_TypeDef *TIMx, TIM_Base_InitTypeDef *Structure)} function is executed. In the SPI1 failure case it happens when __HAL_AFIO_REMAP_SPI1_ENABLE() macro is called. I am using Cube App V4.21, FW V.1.4 and Atollic 7.1.2 Lite. Any idea? Please help.

17 REPLIES 17
AvaTar
Lead
Posted on June 06, 2017 at 13:55

I don't speak Cube, so I can't comment on the expected completeness of this code.

However, the first step would be to turn off all optimizations.

Debugging should then go 'linear' with code.

My second suggestion would be to switch to disassembly (or mixed) display, and check the assembly instruction where you code goes 'off', and the SCB register contents (fault reason) afterwards.

Posted on June 06, 2017 at 14:30

Hi AvaTar, thanks for your advice. I have the optimization set to 'Optimized for Debugging (-Og)', debug level 'Maximum (-g3)' and this should be fine. Yes, I have used the disassembly window (see attached screenshot) and it says 'Unable to retrieve disassembly data from backend'. It looks like some portion of the code is missing or not been linked correctly. Unfortunately I can not pick up a clue how to resolve the issue.

Posted on June 06, 2017 at 14:43

I have the optimization set to 'Optimized for Debugging (-Og)', debug level 'Maximum (-g3)' and this should be fine.

In my experience one should at least remove all optimizations for speed or size.

It looks like some portion of the code is missing or not been linked correctly.

Don't think so. You would get linker errors, and not being able to flash/debug it.

Yes, I have used the disassembly window (see attached screenshot) and it says 'Unable to retrieve disassembly data from backend'. Unfortunately I can not pick up a clue how to resolve the issue.

Hmmmm, me neither. Seems an Atollic issue - not sure if 'backend' means GDB, which is usually run as separate process by Eclipse IDEs. One of the reasons this Eclipse stuff is second/third rate quality for me ...

Maybe some of Atollics project settings or debug settings are incorrect or messed up, but I cant' really help with that.

BTW:

...(see attached screenshot)...

I don't see any attachment ...

Posted on June 06, 2017 at 14:58

0690X00000607FMQAY.png
Posted on June 06, 2017 at 15:04

Ahhh, that is ok.

I (implicitly) meant the assembly context of the function

TIM_Base_SetConfig()

, where crash to the hardfault handler happens. Especially those immediately before.
_Anani Popov
Associate II
Posted on June 08, 2017 at 10:24

Hi All, in the case of ST-Link freezing when 

__HAL_AFIO_REMAP_SPI1_ENABLE() macro is called:

The error message is:

warning: Remote failure reply: E31

Remote failure reply: E31

As a matter of fact the re-map of SPI1 affect AFIO-MAPR register where SWD re-mapping bits are located as well.

Could that be the problem?

_Anani Popov
Associate II
Posted on June 08, 2017 at 10:42

0690X00000607GyQAI.png
Posted on June 08, 2017 at 11:38

As mentioned before, I don't know the Cube code, and certainly not this macros.

But I remember that old adage 'The macro is a coder's declaration of capitulation'.

I suggest you 'statically code-review' this macro, or switch to disassembly in the debugger and check it's execution.

As a matter of fact the re-map of SPI1 affect AFIO-MAPR register where SWD re-mapping bits are located as well.

Could that be the problem?

Might well be, can't recall the MCU specific context here.

At least none of the SWD pins and SPI1 pins share a GPIO directly. Perhaps the macro kills other AFIO config bits as well.

_Anani Popov
Associate II
Posted on June 08, 2017 at 17:04

Guys, there is a bug in STM32F100 HAL remapping scheme when SPI1 is remapped. __HAL_AFIO_REMAP_SPI1_ENABLE() macro is extended to SET_BIT(AFIO->MAPR, AFIO_MAPR_SPI1_REMAP) and further to #define CLEAR_BIT(REG, BIT) ((REG) &= ~(BIT)) macro, which is Read-Modify-Write. Non valid data are read for MAPR SWJ_CFG bits, and sub-sequentially written back to MAPR. In most of the cases the debugger configuration is corrupted and the debugger hangs on. Work out: replace the macro with Read-Modify-Write one where you explicitly cast your debugger mode. In my case is SWD, see the solution below:

void HAL_SPI_MspInit(SPI_HandleTypeDef* spiHandle)

{

  GPIO_InitTypeDef GPIO_InitStruct;

  if(spiHandle->Instance==SPI1)

  {

  /* USER CODE BEGIN SPI1_MspInit 0 */

   uint32_t Temp;

  /* USER CODE END SPI1_MspInit 0 */

    /* Peripheral clock enable */

    __HAL_RCC_SPI1_CLK_ENABLE();

 

    /**SPI1 GPIO Configuration   

    PB3     ------> SPI1_SCK

    PB5     ------> SPI1_MOSI

    */

    GPIO_InitStruct.Pin = SPI_SCK_LCD_Pin|SPI_MOSI_LCD_Pin;

    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;

    HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

    //__HAL_AFIO_REMAP_SPI1_ENABLE();

  /* USER CODE BEGIN SPI1_MspInit 1 */

    //NB:Comment out __HAL_AFIO_REMAP_SPI1_ENABLE(); ^ABOVE^ after CUBE code generation!!!

    Temp = AFIO->MAPR;

  Temp &= 0xF8FFFFFF;  /* Clear whatever was read back in SWJ_CFG      */

  Temp |= 0x02000001;   /* Set SPI Re-map and Set SWJ_CFG to “010â€� for SWD */

  AFIO->MAPR = Temp;

  /* USER CODE END SPI1_MspInit 1 */

  }

}