DA14531 does not boot from SPI master after successful firmware transfer

Hi Kas,

Thank you for posting your question online.

Kas said:

I have also tried uploading a firmware binary that advertises a BLE device but the BLE device does not appear when performing a BLE scan. This firmware binary was tested and works on the official DA14531 development board.

How can I verify that the firmware booted successfully?

1) If the DA14531 should start advertising when it boots up and you can not see it advertising, or the test GPIO you set does not go into High, it seems that the booting process was not successful.
2) Since the same firmware works on the DA14531 Dev Kit, it might be a HW issue of the custom board.
Have you checked the custom board? Had you previously loaded any other firmware that it worked on the custom board?

From my understanding, you are trying to load a program directly into the RAM of the DA14531 via an External MCU. Please refer on the following examples:
1)BLE_SDK6_examples/interfaces/external-processor-stm32 at main · dialog-semiconductor/BLE_SDK6_examples (github.com)

You can follow the same procedure as shown in this example but instead of Codeless use your own custom firmware.
2) BLE_SDK6_examples/interfaces/external-processor-renesas at main · dialog-semiconductor/BLE_SDK6_examples (github.com)



Best Regards,
OV_Renesas

OV_Renesas said:

Had you previously loaded any other firmware that it worked on the custom board?

Yes, there is firmware running on the STM32 successfully. The custom board works (I even tried 2 separate units).

OV_Renesas said:

From my understanding, you are trying to load a program directly into the RAM of the DA14531 via an External MCU

That is correct, I followed the manual I linked titled "Boot from SPI Bus - DA1453x Act as SPI Slave", it seems like the firmware upload works the way it should but clearly something is wrong somewhere 

OV_Renesas said:

You can follow the same procedure as shown in this example but instead of Codeless use your own custom firmware.

Thank you for the examples, I am happy to try using (2w) UART as a booting medium like they do, but since the SPI firmware upload sequence returns an ACK I have doubts if it would make a difference.

FYI, the radio is powered in BUCK configuration with 2V5 on VBAT_HIGH, could this cause booting issues?

Kind regards,
Kas

Hi Kas,

Thank you for the reply.

Kas said:

Yes, there is firmware running on the STM32 successfully. The custom board works (I even tried 2 separate units).

You have tested the custom boards when connected to the STM32 or separately to see if they are working?
From my understanding, those custom boards have the DA14531 SoC and you have not included any external SPI Flash. 
Please correct me if I am mistaken.

Kas said:

That is correct, I followed the manual I linked titled "Boot from SPI Bus - DA1453x Act as SPI Slave", it seems like the firmware upload works the way it should but clearly something is wrong somewhere 

Please try and follow the available example with STM32. 
You can also refer on this option: ezFlashCLI/ezFlashCLI/serialCLI.py at main · ezflash/ezFlashCLI (github.com)

Kas said:

Thank you for the examples, I am happy to try using (2w) UART as a booting medium like they do, but since the SPI firmware upload sequence returns an ACK I have doubts if it would make a difference.

Have you checked that the CRC check was OK after the transfer?
Is it possible to attach a debugger on the DA14531 while the program runs on the RAM and check with Ozone if it crashes somewhere?

Kas said:

FYI, the radio is powered in BUCK configuration with 2V5 on VBAT_HIGH, could this cause booting issues?

Based on AN-B-075, on page:12:



There should not be an issue with 2.5V on VBAT_HIGH.
However, if you could test it at 3V that would be good.

Best Regards,

Hi Kas,

Thank you for the reply.

Kas said:

Yes, there is firmware running on the STM32 successfully. The custom board works (I even tried 2 separate units).

You have tested the custom boards when connected to the STM32 or separately to see if they are working?
From my understanding, those custom boards have the DA14531 SoC and you have not included any external SPI Flash. 
Please correct me if I am mistaken.

Kas said:

That is correct, I followed the manual I linked titled "Boot from SPI Bus - DA1453x Act as SPI Slave", it seems like the firmware upload works the way it should but clearly something is wrong somewhere 

Please try and follow the available example with STM32. 
You can also refer on this option: ezFlashCLI/ezFlashCLI/serialCLI.py at main · ezflash/ezFlashCLI (github.com)

Kas said:

Thank you for the examples, I am happy to try using (2w) UART as a booting medium like they do, but since the SPI firmware upload sequence returns an ACK I have doubts if it would make a difference.

Have you checked that the CRC check was OK after the transfer?
Is it possible to attach a debugger on the DA14531 while the program runs on the RAM and check with Ozone if it crashes somewhere?

Kas said:

FYI, the radio is powered in BUCK configuration with 2V5 on VBAT_HIGH, could this cause booting issues?

Based on AN-B-075, on page:12:



There should not be an issue with 2.5V on VBAT_HIGH.
However, if you could test it at 3V that would be good.

Best Regards,

Hi PT,

> From my understanding, those custom boards have the DA14531 SoC and you have not included any external SPI Flash.
Sorry for the confusion. There is indeed no external SPI flash. There is a single PCB containing an STM32 processor and a DA14531 SoC (and other components that are required to accommodate them). I cannot separate these. The 2 boards I spoke of were 2 identical PCBs, they are not used at the same time. I know for sure the STM32 is working and that the STM32 can communicate with the DA14531 bootloader.

> Have you checked that the CRC check was OK after the transfer?
Yes, the final byte received from the DA14531 (SPI slave) is 0x02 (see my first post for the rest of the response bytes). I have also tried corrupting the CRC (CRC+1) and that prompts a final response of 0x20 (NACK).

> Is it possible to attach a debugger on the DA14531 while the program runs on the RAM and check with Ozone if it crashes somewhere?
I was able to connect the debugging pins and use GDB to connect to the device. Attempting to step or set breakpoints causes a HardFault, but I can continue and interrupt the code as many times as I want and see that my firmware is indeed running on the device (by using "where" to see the call stack). I am also able to "load" firmware using GDB but the results are the same: The device still does not advertise as a BLE peripheral like the development board does with the same firmware.

On another note, I have noticed many examples call the following function in periph_init:

// In Boost mode enable the DCDC converter to supply VBAT_HIGH for the used GPIOs
syscntl_dcdc_turn_on_in_boost(SYSCNTL_DCDC_LEVEL_3V0);

I have now added:
syscntl_dcdc_turn_on_in_buck(SYSCNTL_DCDC_LEVEL_2V5);
to my code, but I was surprised I did not know about this function yet. Is there any documentation for code changes that are required for custom hardware?

Kind regards,
Kas

P.S. I have also made a post about another issue I noticed when attempting to connect the debugger:
community.renesas.com/.../da14531-swd-only-connects-after-programming-firmware

Hi,

This reply is an extension of my reply 6 days ago to make sure this issue is still on the radar, and to add a few updates:
- I have changed the function call syscntl_dcdc_turn_on_in_buck(SYSCNTL_DCDC_LEVEL_2V5); that I added to SYSCNTL_DCDC_LEVEL_1V8 because that is the desired VBAT_LOW level.
- I have found the (undocumented?) SDK define `CFG_WLCSP_PACKAGE`, which I have added to da145xx_config_advanced.h because we are using a DA14531 WLCSP package. This brings me back to the question: are there any other configuration options that must be defined/configured differently for custom boards?

These changes have unfortunately not fixed the issue, the DA14531 still appears largely nonfunctional.

Kind regards,
Kas

Hi Kas,

Thank you for the replies and apologies for the delay.

Kas said:

This brings me back to the question: are there any other configuration options that must be defined/configured differently for custom boards?

There are not specific changes required in the code in order to use the DA14531 in custom boards.

Kas said:

P.S. I have also made a post about another issue I noticed when attempting to connect the debugger:
community.renesas.com/.../da14531-swd-only-connects-after-programming-firmware

On this ticket you have mentioned the possibility to raise a private ticket.
Please refer here: Dashboard | Renesas Customer Hub
You can sign in with your MyRenesas Account and raise a private ticket.

1) Please share Schematics and Layout files so we can do a HW review.
2) After we have verified that the custom board does not have any HW issues let's continue on the SW side.
Did you try our available examples for the STM32 + DA14531?

Best Regards,
OV_Renesas