cancel
Showing results for 
Search instead for 
Did you mean: 

STM32f429 discovery board binary file issues

paramasivan
Associate II
Posted on November 11, 2014 at 14:15

Hi,

I have created a binary of STM32f429 demostration application code by using IAR workbech. Program the firmware upgrade code in to the discovery board by Jlink debuger. I tried to upload the binary file through the USB key, but its not working. But i wonder, the example binary file ''STM32F429I-Discovery_LTDC_ColorKeying_0x08020000.bin'' working fine. Why the IAR workbench created bin file is not working? How to create a compatible  bin file for this discovery board?

The binary file size of demo application is 999 Kb. Is there any code size limit in the firmware upgrade program?

#rewrite #stm32f4 #usb #eeprom #discovery #flash #stm32f #st-link/v2-stm32f4discovery
12 REPLIES 12
Posted on November 11, 2014 at 16:57

Well the code has to fit within the flash memory, and has to be compiled/linked for the correct address, which is apparently +128KB into the memory, at 0x08020000

Configure your tools appropriately. Either via the target GUI, or linker script (.ICF)
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
paramasivan
Associate II
Posted on November 14, 2014 at 13:04

Thanks for the reply. Now I have modified the flash address to 0x08008000 in the linker file and changed the FLASH_BASE value the same in the code. My bootloader code is running from default start address (0x8000000). Bootloader code successfully redirect to the application code in the debugger mode only. It doesn't work in power on reset. It hangs some where else. Is there any vector problem in power on reset? Working fine in debugger mode. Also i got a warning message in debug log when i try to _set_MSP to

my application address (0x08008000).

The stack pointer for stack 'CSTACK' (currently 0x20000808) is outside the stack range (0x20009410 to 0x2000B410) 

I am using Jlink and IAR workbench. Thanks in advance. 

Posted on November 14, 2014 at 13:50

Ok, so what exactly are you using here? You're mixing things up and I'm not keeping track.

0x08008000 != 0x08020000

Do you have an STM32F4-DISCO or STM32F429I-DISCO ? What code are you attempting to build?

STM32F429I-Discovery_FW_V1.0.1\Projects\FW_upgrade\src\main.c ??

If you changed the app load address, is that changed in the boot loader too?

If the Clocks and PLL are already running you might want to change the code SystemInit() calls so as not to tear down a working clock configuration.

If the debugger changes the behaviour, then output diagnostic/telemetry information via a serial port and track down the failure that way.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
paramasivan
Associate II
Posted on November 14, 2014 at 14:14

Hi Clive,

I have stm32f429I-Disco board and try to flash the demonstration code trough USB key. Yes , now i have modified the application address to 0x8008000, made the change in to bootloder code as well.  

Actually i am trying to implement the bootloader in to my custom board. I have the same problem in discovery board and custom board too. For problem diagnostic, do i need to implement UART in my bootloader code? 

Posted on November 14, 2014 at 15:12

For problem diagnostic, do i need to implement UART in my bootloader code?

I would, depends what visibility you want, and how you can debug things.

With Keil it's possible to debug boot loader and application, I would imagine similar things are possible with IAR. At the very least stepping the disassembly across the transition.

You might want to add a Hard Fault handler that can display diagnostic information if you think it;'s crashing that way. Joseph Yiu has published a couple of handlers, and has his books on the Cortex parts.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
paramasivan
Associate II
Posted on November 18, 2014 at 15:40

Still the proble persisits,

I have enabled UART and print the message where the loop hang inside the code. My bootloader code strucks inside hard fault handler when execute 

 if (STM_EVAL_PBGetState(BUTTON_USER) == Bit_SET)

It only happenes in the release mode. Debugger mode works fine. What could be the problem ? Is there any good method to find the problem to print through UART.

Here is my Main Loop,

int main(void)

{

  /* STM32 evalboard user initialization */

  BSP_Init();

  init_USART6(9600);

  ALARM_LED_Config();

  USART_puts(USART6, ''Init complete! Hello World!\r\n''); // just send a message to indicate that it works

  

  /* Flash unlock */

  FLASH_If_FlashUnlock();

  

  /* Test if User button on the Discovery kit is pressed */

 if (STM_EVAL_PBGetState(BUTTON_USER) == Bit_SET)

  {

    /* Check Vector Table: Test if user code is programmed starting from address 

       ''APPLICATION_ADDRESS'' */

    if (((*(__IO uint32_t*)APPLICATION_ADDRESS) & 0x2FFE0000 ) == 0x20000000)

    {

      

      FLASH_Lock();

      

      USART_puts(USART6, ''Jumb to app\r\n'');

      

      /* Jump to user application */

      JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);

      Jump_To_Application = (pFunction) JumpAddress;

      /* Initialize user application's Stack Pointer */

      __set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);

      Jump_To_Application();

    }

 }

  

  USART_puts(USART6, ''Init USBH\r\n'');

  /* Init Host Library */

  USBH_Init(&USB_OTG_Core, USB_OTG_FS_CORE_ID, &USB_Host, &USBH_MSC_cb, &USR_Callbacks);

    

  while (1)

  {

    /* Host Task handler */

    USBH_Process(&USB_OTG_Core, &USB_Host);

  }

}

Thanks in advance.

Posted on November 18, 2014 at 16:59

And with your Hard Fault Handler, are you identifying the code, registers and memory involved in the fault? Does that suggest where the problem lies?

http://blog.frankvh.com/2011/12/07/cortex-m3-m4-hard-fault-handler/

I might also print out the address of the stack, as represented by hardfault_args

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
paramasivan
Associate II
Posted on November 19, 2014 at 12:05

Thanks for your reply.

I have modified my main loop, I just reinitialize the application vector address and disable the USART before jump. After this modification my bootloder works fine in power on reset. 

But now i am facing a major problem while reading the USB, It struck on the COMMAND_ProgramFlashMemory function,

(HCD_IsDeviceConnected(&USB_OTG_Core) == 1)  returns value 0. Again its work in the debugger mode only. 

Why its working on the debugger mode only? What is the major different ?

Note

: Power on reset works only after i enable the USART in bootloder code. 

if (((*(__IO uint32_t*)APPLICATION_ADDRESS) & 0x2FFE0000 ) == 0x20000000)

    {

      

    //  FLASH_Lock();

      

     USART_puts(USART6, ''Jumb to app\r\n'');

     

     NVIC_DisableIRQ(USART6_IRQn);

      NVIC_SetVectorTable(0x08008000, 0x00);

      /* Jump to user application */

      JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4);

      Jump_To_Application = (pFunction) JumpAddress;

      /* Initialize user application's Stack Pointer */

      __set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);

      Jump_To_Application();

    }

 }

Thanks in advance.

paramasivan
Associate II
Posted on November 20, 2014 at 15:55