DA14530 Booting from 2-wird UART not SPI slave issue.

Hi There,

Thank you for posting your question online.

00u18c18kvkwzgwmH358 said:

Currently on a customized board, the DA14530 needs to be enabled via 2-wired UART.
But when I do the REST PING action, RX only receives 0x00 and not 0x02. Why is this?

Please share more information, it is not clear to us what exactly you are trying to do. 
Is there a Host MCU? Are you trying to load the FW directly into the DA14530 SRAM?

00u18c18kvkwzgwmH358 said:

There was originally a flash on the customized board but it has been removed. Will this have any impact?

Were you able to program the DA14530 via 2-Wire UART when the SPI Flash was in place?

00u18c18kvkwzgwmH358 said:

My EVB board is normal.

Are you referring on the Dev Kit Pro?

Best Regards,
Orestis

Hi 

OV_Renesas said:

Please share more information, it is not clear to us what exactly you are trying to do. 
Is there a Host MCU? Are you trying to load the FW directly into the DA14530 SRAM?

Yes,I  trying to load the FW directly into the DA14530 SRAM.(https://lpccs-docs.renesas.com/DA14535/AN-B-072-DA14531-Booting-from-serial-interfaces/Booting%20from%20a%20Custom%20PCB/Booting%20from%20a%20Custom%20PCB.html)

I'm Booting from a Custom PCB with 2-wire uart.
Currently, P0_0 is down by default. Then, pull-high and then pull-down P0_0 to generate RST trigger. DA14530 expected to send STX (0x02) packets but received 0x00.
Does P0_0 maintain high frequency by default? Will STX only be sent once?

OV_Renesas said:

Are you referring on the Dev Kit Pro?

Yes.

Hi There,

Thank you for the reply.
You can also refer here: 6. Appendix — DA14585/DA14531 SW Platform Reference Manual (renesas.com)


Regarding the P0_0 (HW Reset):
Please refer on DA14530 Datasheet, on section 5. Reset, page:50

And from Pinout:

And on AN-B-075: DA14530/531 Hardware Guidelines (renesas.com), on section A.2 Booting Sequence and P0_0, page:41


Finally the procedure for UART boot should look like this:


Are you using an External MCU or SmartSnippets Toolbox to download the FW into the DA14530 SRAM?

00u18c18kvkwzgwmH358 said:

Will STX only be sent once?

Yes, STX will be sent only once. In case of Fail you will have to restart the procedure.


Best Regards,
OV_Renesas

Hi There,

Thank you for the reply.
You can also refer here: 6. Appendix — DA14585/DA14531 SW Platform Reference Manual (renesas.com)


Regarding the P0_0 (HW Reset):
Please refer on DA14530 Datasheet, on section 5. Reset, page:50

And from Pinout:

And on AN-B-075: DA14530/531 Hardware Guidelines (renesas.com), on section A.2 Booting Sequence and P0_0, page:41


Finally the procedure for UART boot should look like this:


Are you using an External MCU or SmartSnippets Toolbox to download the FW into the DA14530 SRAM?

00u18c18kvkwzgwmH358 said:

Will STX only be sent once?

Yes, STX will be sent only once. In case of Fail you will have to restart the procedure.


Best Regards,
OV_Renesas

Hi 

Thank you for the reply.

OV_Renesas said:

Are you using an External MCU or SmartSnippets Toolbox to download the FW into the DA14530 SRAM?

No, I wrote a tool (similar to cli_flash_programming) to load fw into the BLE memory for execution.

OV_Renesas said:

And on AN-B-075: DA14530/531 Hardware Guidelines (renesas.com), on section A.2 Booting Sequence and P0_0, page:41

OV_Renesas said:

Yes, STX will be sent only once. In case of Fail you will have to restart the procedure.

So according to the description, RST must be maintained in a high state. STX will be sent only after the first pull-down. Subsequent RSTs have no effect? ​​Do you have to wait for a restart before sending STX again?

Hi There,

Thank you for the reply.

00u18c18kvkwzgwmH358 said:

No, I wrote a tool (similar to cli_flash_programming) to load fw into the BLE memory for execution.

Are you sure that your custom tool works as expected? 
Are you facing the same issue with CLI or SmartSnippets Toolbox?

00u18c18kvkwzgwmH358 said:

So according to the description, RST must be maintained in a high state. STX will be sent only after the first pull-down. Subsequent RSTs have no effect? ​​Do you have to wait for a restart before sending STX again?

The HW Reset, triggers the ROM bootloader. It will then go through all the Booting Steps.
You should trigger the HW Reset again before waiting to receive STX.

Best Regards,
OV_Renesas

Hi 

Thank you for the reply.

OV_Renesas said:

Are you sure that your custom tool works as expected? 
Are you facing the same issue with CLI or SmartSnippets Toolbox?

When I use the EVB board, there is no problem. I can receive STX packets even when I press the reset button.

OV_Renesas said:

The HW Reset, triggers the ROM bootloader. It will then go through all the Booting Steps.
You should trigger the HW Reset again before waiting to receive STX.

What I want to confirm is whether STX will only be sent once after the customized board is powered on? Because according to the description, P0_0 will revert to TX after the first pull-down. If you want to send STX packets again, you must restart (power off/on)? Is this understanding correct?
Currently encountering a problem, the default state is low. For P0_0 pull-high and then pull-down, a 0x00 packet is received.
Therefore, we need to change it to the default high state and pull-down P0_0 through gpio control before sending the STX packet?

Hi There,

Thank you for the reply.

00u18c18kvkwzgwmH358 said:

If you want to send STX packets again, you must restart (power off/on)? Is this understanding correct?

Yes, that is correct.

00u18c18kvkwzgwmH358 said:

Currently encountering a problem, the default state is low. For P0_0 pull-high and then pull-down, a 0x00 packet is received.
Therefore, we need to change it to the default high state and pull-down P0_0 through gpio control before sending the STX packet?

I used the following command with CLI:

SmartSnippetsToolbox.exe -type booter -chip DA14531 -com_port 48 -uart P0_0 -file flash_programmer_531.bin

My connections on the Dev Kit Pro are the following:


The result from CLI:

Launching SmartSnippets Toolbox v5.0.24.4128
Loaded the following properties from C:\Users\ovasinio\SmartSnippetsToolbox\properties.txt
{Enable_FlashCode_NVParams=true, Enable_FlashCode_ProductHeaderBackup=true, Enable_FlashCode_ConfigurationScript=true, ENABLE_PART=true, Enable_FlashCode_FirmwareImage1=true, ENABLE_HIDDEN_TOOLS=true, ENABLE_TS=true, Enable_FlashCode_FirmwareImage2=true, Enable_FlashCode_ProductHeader=true, ENABLE_MP=true, ENABLE_TE=true}
Command line arguments:
-type booter -chip DA14531 -com_port 48 -uart P0_0 -file flash_programmer_531.bin
Connection to COM48 port has successfully opened.
Started download procedure...
Please press the hardware reset button on the board to start the download process.
Reset detected
Successfully disconnected from port COM48.
Successfully downloaded firmware file to the board.

During this procedure I had probed a logic analyzer on P0_0 and P0_1:

After the HW Reset, I zoom in the P0_1:

Indeed we receive 0x00, which is expected since P0_1 original state is Pull Down:

In less than 5ms the ROM bootloader has been loaded and P0_1 is configured for UART operation. We then immediately receive 0x02 (STX)

We proceed then with SOH from P0_0

Finally we can see that P0_1 responds with ACK (0x06) and we start sending the FW.

I did this on DA14531 but the exact same sequence applies for DA14530.

I think that the 0x00 packet you receive on P0_1 is due to the Initial Reset state of P0_1 after the HW Reset and before the ROM bootloader has started. After this you do not receive the 0x02 at all?

If this issue persists, please share with us your Schematic and Layout files so we can submit them for a HW Review.

Best Regards,
OV_Renesas

Hi

Thank you for the reply.

OV_Renesas said:

I think that the 0x00 packet you receive on P0_1 is due to the Initial Reset state of P0_1 after the HW Reset and before the ROM bootloader has started. After this you do not receive the 0x02 at all?

I only received 0x00 packets but not STX (0x02) packets. What could be the reason?

Hi There,

Thank you for the reply.

00u18c18kvkwzgwmH358 said:

I only received 0x00 packets but not STX (0x02) packets. What could be the reason?

The ROM Bootloader might be "stuck" on another boot step expecting a reply.

We would need to see your Schematic and Layout files to determine that there is not an issue with the HW.
If you do not want to share them here (Public forum), you can create a private ticket.
For Private Tickets please refer here: Technical Support Services | Support Forums & Ticket Assistance - Renesas | Renesas

You can reference this Forum ticket so we can keep track of your issue. 
Everything on the Private tickets is confidential. 
We can submit your design for a HW Review by our BLE HW Support Team.

Best Regards,
OV_Renesas

Hi 

Thank you for the reply.

I will submit an issue as you suggested.

Finally, I want to confirm something. Is P0_0 of default and picture supposed to be high or low instead  after first power-on?

Hi There,

Thank you for the reply.

00u18c18kvkwzgwmH358 said:

Is P0_0 of default and picture supposed to be high or low instead  after first power-on?

It should be high while the ROM Bootloader is running.

Best Regards,
OV_Renesas

Hi 

Thank you for the reply.

I've submitted an issue.
Ticket: 393829.
Please help push it. Thank you.