DA14531 stops execution after reset

Hi,

I am using SmartBond Flash programmer tool to download the firmware to DA14531. I noticed that after programming, application executes well, however after resetting the board, it does not start again. It seems like it is not executing from flash, or there is some other setting that I am missing. I haven't noticed some options in SmartBond programmer tool where I can influence execution. Previously, I was using DA14531 only in debug mode with the Keil IDE.

Regards,

Igor

Parents
  • Hi Igor,

    Thank you for posting your question online.
    Yes, this is strange. DA14531 should boot from SPI Flash since you have burned your FW there.
    Have you burned anything inside OTP Header?
    Can you try using the SmartSnippets Toolbox which you can find here: SmartBondTm Development Tools | Renesas
    After installing the SmartSnippets Toolbox, go to the Programmer Tab and select the Flash Code option. Then you should select Import from File.


    Select the Bootable Option. Find from Browse your hex/bin file and press Finish. 
    Press the Connect button, then Read the content of your Flash and then Burn the Flash. 
    After all that try to reset your device to see if it will boot from the SPI Flash. 
    If it does not work again, try to Connect and read the contents of your SPI Flash to see if everything is inside.
    I would also recommend checking DA14531 Datasheet, 4.5 BootROM Sequence, page: 66, you can find the BootROM Sequence:

    As you can see before we try to boot from SPI Flash, we check the Boot Specific Flag = 0xAA. 
    You can find on page 62 of DA14531 Datasheet:

    You can go on SmartSnippets Toolbox-> Programmer->OTP->Read->Start Address(Hex): 0x07F87FC8 and see it:


    Kind Regards,
    OV_Renesas

  • Hi,

    Thank you for comprehensive answer. I read OTP and in my case all values are 0xFF (don't know why), no Boot Specific Flag 0xAA.

    Is there a way to fix it?

    Thank you in advance.

    Regards,

    Igor

  • Hi Igor, 

    The values 0xFF means that this memory is empty. 
    When you say you reset the board, you mean that you pressed the Switch 1 on DevKit Pro which is the Reset button or that you powered down completely your device and tried to power it up again?
    If you pressed the reset button you should be able to run the FW from the Flash.
    In the case that you powered down your device and tried to power it up again it is logical that it would not boot since you do not have burned the boot specific flag. 
    The OTP is an only one-time programmable memory, so I would recommend burning anything there at the end of your project.
    As you can see in the Screenshot below, you can see System Parameters in the OTP Header. From there you can burn (following the DA14531 Datasheet about each memory address) the OTP with the configuration you want for your device. 

      
    I would also recommend to keep in mind the following:
    SmartSnippets Toolbox-->Configurator-->Board Setup
    From there you can decide if you want to burn Flash, RAM or OTP with other Serial Interfaces.

    Kind Regards,
    OV_Renesas

  • Hi,

    Thank you very much for the clarification. Yes, I restart the board by power off/power on cycle.

    I noticed one more thing with resetting. I also have implemented software reset (using platform reset function) in my code. Software reset works well - board boots up correctly after performing it. However, after the first SPI flash write (I used proper part in SPI flash for permanent storage of some data, like it is used for bond database) I cannot perform the software reset any more. Everything functions well after SPI flash write, but once I call platform reset, it does not boot any more. Before SPI flash write, platform reset works well. The base addresses I used for storing data in SPI flash are 0x20000 and 0x23000 and I store up to 12 bytes in each region with one sector erase (4096 bytes) before data write for those regions. I don't know if those things are somehow related. 

    Regards,

    Igor

  • Hi Igor,

    Can you search if you have implemented somewhere in your code the following line:

     // Disable HW Reset functionality of P0_0
        GPIO_Disable_HW_Reset();

    This function disables the HW Reset. 
    According to DA145xx Tutorial SDK6 Peripheral Drivers: DA145XX Tutorial SDK6 Peripheral Drivers — DA145XX Tutorial SDK peripherals (renesas.com)

    I suppose that you are working with our DK Pro. If you are not working with DK-Pro which Flash module are you using? How have you configured it?

    Kind Regards,
    OV_Renesas

  • HI,

    Yes, that line of code is implemented. I am using DK Pro. 

    Regards,

    Igor

  • Hi Igor, 

    If you want to use the HW Reset to see if you can boot from Flash, you should comment that line out. Another way to see if your device can boot from Flash is to enter Deep Sleep or Hibernation Sleep mode and wake up via the wake-up controller. 

    The base address 0x20000 could overlap over the section where we store the bonding table (if you are using it), otherwise there should not be a problem with your SPI write.

    Could you try again without the GPIO_Disable_HW_Reset(); function and share the results? 
    If this does not work, can you try SPI write in some other base addresses, so we be sure that this is also not an issue?

    Kind Regards,
    OV_Renesas

  • Hi Team,

    Let me share my results.

    Commenting GPIO_Disable_HW_Reset(), does not make any change to power off/power on sequence (device does not boot after). This is expectable as there is no boot specific flag in OTP memory, as you pointed earlier.

    With  GPIO_Disable_HW_Reset() commented, I cannot write to flash. I then uncommented this line, but changed spi flash base addresses to be 0x30000 and 0x34000 instead of 0x20000 and 0x23000. Now, spi flash write works, and also I can do platform reset after write. With base address I had earlier, platform reset does not work after spi flash write. It seams the platform reset problem is related to the space I am accessing for write.

    According to flash memory layout given in this tutorial, 0x0003 FFFF address is referred as available for user data storage for up to 128kB. Does it mean that I can use any address in this range (128kB space starting from 0x0003 FFFF), like 0x0004000 and up? 

    Regards,

    Igor

  • Hi Igor,

    As you stated GPIO_DISABLE_HW_RESER() would not affect the boot sequence after power off/power on. 
    By commenting out GPIO_Disable_HW_Reset() you should be able to write to flash. Do you use P0_0 in your SPI configuration? That might be the reason why. 
    Let me try to explain the SPI memory layout on DevKit Pro:
    We have 256kBytes available. => 256kb *1024 = 262144 bytes.
    We start from the address 0x00000000, and we can use up to 48kB for our code (48kB is the RAM so we could not store a larger FW since we will copy it on the RAM when we boot).
    Our code could reach up to address: 0x0000BB80. We leave 512 bytes reserved.
    Then we can use from the address: 0x0000BD80 up to 0x0001DE90 for User data storage. We leave 368 bytes reserved.
    From the address: 0x0001E000 up to 0x0001FF40 we store the bonding table.
    The address 0x0003FFFF is the END of the Flash memory:

    So, you can use for user data storage from 0x0001FF40 up to 0x0003FFFF.
    It is a bit tricky because on the Tutorial it gives the start address for the 3 Memory layouts and for the last one it gives the last address of the SPI Flash. 

    You could use SmartSnippets Toolbox to Connect and Read the Flash to see what is exactly inside the address: 0x20000 and 0x23000 and why erasing it and re-writing it causes this problem. Add a BKPT before the SPI Flash, read the specific addresses and then read them again after SPI write. 
    I believe you would be able to monitor it through Memory window on Keil too if you have debugger attached. 

    PS. If you found any answer helpful for your problem you could accept it, that would help the community. 

    Kind Regards,
    OV_Renesas

  • Hi Team,

    Thank you for very valuable support. Great clarification of the memory map and end address.

    I am using P0_0 according to spi configuration code:

    /****************************************************************************************/
    /* SPI configuration                                                                    */
    /****************************************************************************************/
    #define SPI_EN_PORT                     GPIO_PORT_0
    #define SPI_EN_PIN                      GPIO_PIN_1
    #define SPI_CLK_PORT                    GPIO_PORT_0
    #define SPI_CLK_PIN                     GPIO_PIN_4
    #define SPI_DO_PORT                     GPIO_PORT_0
    #define SPI_DO_PIN                      GPIO_PIN_0
    #define SPI_DI_PORT                     GPIO_PORT_0
    #define SPI_DI_PIN                      GPIO_PIN_3

    I erased flash, downloaded the code and read the flash content with SmartSnippet Toolbox. I noticed that starting from 0x20000 there is some content.

    It seems that I didn't have luck when choosing address for storing data as from this address there is some content. It is difficult to reveal what is that content. I didn't write anything in flash before read,  so it is questionable what is this. I am using bond database, maybe it is part of it, however I didn't create any bond before read and previously complete flash was erased.

    According to some rough analysis, the free content begins from this:

    Therefore, choosing base addresses of 0x30000 and 0x34000 seems safe, so the platform reset problem disappeared.

    I hope this will help someone with similar problems.

    Regards,

    Igor

  • Hi Igor,

    The GPIO_Disable_HW_Reset is inside the gpio.h file:

    /**
     ****************************************************************************************
     * @brief Disable hardware reset functionality on P00.
     ****************************************************************************************
     */
    __STATIC_FORCEINLINE void GPIO_Disable_HW_Reset(void)
    {
        SetWord16(HWR_CTRL_REG, 1);
    }

    From the DA14531 Datasheet, 31.11 Miscellaneous Registers, page:260

    This is the reason you could not use SPI write while using this function.
    Even the SW reset could be affected by this function. But if you want to implement a SW reset and use SPI write you can just configure another pin (not used in SPI) using the following function:
    /**
     ****************************************************************************************
     * @brief Enable the GPIO Power-On Reset (POR) source.
     * @param[in] port          GPIO port
     * @param[in] pin           GPIO pin
     * @param[in] polarity      GPIO por pin polarity. 0 = Active low, 1 = Active high.
     * @param[in] por_time      Time for the Power-On Reset to happen. The time is calculated
     *                          based on the following equation:
     *                          Time = por_time x 4096 x RC32 clock period
     ****************************************************************************************
     */
    void GPIO_EnablePorPin(GPIO_PORT port, GPIO_PIN pin, GPIO_POR_PIN_POLARITY polarity, uint8_t por_time);
    

    Regarding the address 0x00020000 on the SPI Flash:
    Have you integrated SUOTA on your project? What you shared is clearly an Image Header for SUOTA.
    As you can see in SUOTA Tutorial: 24. SUOTA Memory Layout — DA145XX Tutorial SDK Getting started (renesas.com)

    Check the memory Layout for SUOTA if you are using it in your project. If you are not using it be sure to go to user_modules_config.h file and exclude the SUOTAR from your project.
    I hope this helps.

    Kind Regards,
    OV_Renesas

  • Hi Team,

    Thank you for suggestion regarding reset pin.

    For the SUOTA, yes, I was trying to implement this as final part of our project, but I didn't have space for it so I postponed that part until the end. However, currently everything is excluded, even suotar files are removed from project. It is strange that when I download firmware with SmartBond Programmer it shows pP that indicates multipart image header, as you pointed. I erased all the flash and then program it, and still appears. This header pP also appears on the first location - 0x0. I am not sure if burning with SmartSnippets makes changes. It is difficult to use because for some reason I am issuing problems with that app tool - graphics start flashing very soon after app start, layout moves as I move mouse pointer, as you can see on this screenshot.

    Regards,

    Igor

Reply
  • Hi Team,

    Thank you for suggestion regarding reset pin.

    For the SUOTA, yes, I was trying to implement this as final part of our project, but I didn't have space for it so I postponed that part until the end. However, currently everything is excluded, even suotar files are removed from project. It is strange that when I download firmware with SmartBond Programmer it shows pP that indicates multipart image header, as you pointed. I erased all the flash and then program it, and still appears. This header pP also appears on the first location - 0x0. I am not sure if burning with SmartSnippets makes changes. It is difficult to use because for some reason I am issuing problems with that app tool - graphics start flashing very soon after app start, layout moves as I move mouse pointer, as you can see on this screenshot.

    Regards,

    Igor

Children
  • Hi Igor,

    Since you are not trying to burn the flash with a multi-image the value on the address location 0x0000000 does not correspond to a SUOATA Multipart Image Header. 
    The value 70 50 in the first address indicates that we want to boot from the Flash. 
    You can see (if you are using SmartSnippets Toolbox) that when you insert a file and have NOT selected the bootable option there will not be these bytes there. 
    With SmartBond Programmer we take as granted that you want to boot from SPI Flash so each time you will see these bytes in the first address. 

    Regarding the SmartSnippets Toolbox App, I had this problem only one time when my HDMI cable got disconnected. I am pretty sure it is a graphics driver problem. 


    Kind Regards,
    Orestis