Programing custom board using 1-Wire with DevKit Pro

Hi Harish,

Thank you for posting  your question online.
Can you make sure that you have not downloaded any FW previously on your custom board that disables the HW Reset pin?
The HW Reset pin is disabled by the following function:

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

Harish said:

I followed the description as mentioned in AN-B-072 to use 1-Wire UART programming, but I could program DA14531MOD daughter board connected to DevKit Pro. However, I want to burn the flash on my custom board. I have tried to power it from the DevKit Pro and connected custom board P0_5 to DevKit Pro P25 on J2 but could not make it. When I choose Board -> Device Info/Detect Device it askes to press RESET and it never detecting that I pressed the reset. It working fine with DA14531OD Daughter board though.

For the DA14531MOD Daughter board we are following this configuration of the Dev Kit Pro in order to program it via 1-Wire UART.

By placing the jumpers on J1, we Connect a 1kΩ resistor between Rx-Tx and we use P0_5.
So, please refer on UM-B-141:

Try to add a 1kΩ resistor between P0_6 and P0_5.

Kind Regards,
OV_Renesas

Hi OV_Renesas,

Thank you for looking into it and replying.

OV_Renesas said:

Can you make sure that you have not downloaded any FW previously on your custom board that disables the HW Reset pin?

I have not disabled REST pin. The reset functionality is working fine when I burn using SWD(SWDIO/SWCLK) and also the current burnt code is working fine and RESET also working fine.

OV_Renesas said:

You could also use the SWD interface, program your custom board but after that you will not be able to access it again via SWD

Yes, I would like to use 1-WIre permanently on my custom board so even if it does not work with SWD it is fine.

I followed the same jumper settings as mentioned in 5.9.1. As mentioned I could do program on Daughterboard so these jumper settings are correct. The problem is programming custom board. I have already connected the MB2_5 to P0_5 on my custom board as mentioned in the Table-5 in UM-B-141 and Table-4. But still it was not detecting the RESET event when I press the RESET button on custom board. 

So, my connections are correct as you suggested. And also I have SWD pins as well and I could program through them without any problem on my custom board(I still did not disabled SWD pins on my custom board hence its working fine). 

I will connect Logic Analyzer on P0_5 and REST on my custom board and will see what is happening on those pins.

Thanks,

Harish.

Hi OV_Renesas,

Thank you for the detailed explanation.

I think, now I am almost there to achieve what I want with my custom board.

OV_Renesas said:

Do you need to have the P0_5 configured for the sensor the whole time or only when the sensor is configured and you want to use it as an input on the wake-up controller? 

Yes, as of now I am using it all the time by pulling it to LOW from the application startup and will make it HIGH only when a sensor is to be made active.

However, as P0_5 was used in system programming and my code is interfering with it, let me exchange this with another pin, like P0_6, and use this P0_5 as UART, so that I need not held it LOW for a long time.

I will try and will update you.

OV_Renesas said:

You can also perform 1-wire UART programming with P0_3.
Edit: You can perform 1-Wire UART programming via P0_3 but P0_3 is not exposed on the module, so do not take it into account. 

Yes, even when I read the documentation I was very happy that I can use P0_3 1-Wire to reprogram my module but then I realized DA14531MOD does not expose it.

And now, as for my two custom boards, I have disabled SWD and burned the code with 1-Wire once, now I am not able to use either 1-Wire or SWD to reprogram them. I will use the other boards as I have ample for testing, however, wondering what is the other way to make these work back by erasing the existing code? Now, I need to look for 2-wire programming(yet to read the documentation) at least to make them usable again.

Thanks,

Harish.

Hi Harish,

Thank you for the reply.

Harish said:

And now, as for my two custom boards, I have disabled SWD and burned the code with 1-Wire once, now I am not able to use either 1-Wire or SWD to reprogram them.

You could try the two following scenarios:
1) Connect your pressure sensor and the moment the EN pin is triggered to High the P0_5 will be available, and you should be able to connect via SST and try to erase the Flash.
2) You can connect P0_5 to High manually, then press connect on SST and instantly remove the P0_5 from High and press the RST button. There is a good chance that the Connect will go through and you are going to be able to erase the SPI Flash.

Harish said:

Now, I need to look for 2-wire programming(yet to read the documentation) at least to make them usable again

I am afraid you will not be able to use 2-Wire UART programming for the DA14531MOD. For 2-Wire UART programming we are using P0_0 and P0_1, both of them are being used by the SPI Flash and the P0_1 is not exposed in the module. 
In order to use 2-Wire UART programming you will have to set different Pins for the SPI Flash Pins, but on the DA14531MOD the SPI pins are fixed and not exposed so it will not be possible.

Harish said:

I will try and will update you.

Please try it and share any feedback.

Kind Regards,
OV_Renesas

Hi OV_Renesas,

OV_Renesas said:

2) You can connect P0_5 to High manually, then press connect on SST and instantly remove the P0_5 from High and press the RST button. There is a good chance that the Connect will go through and you are going to be able to erase the SPI Flash.

Thanks a lot for the options. Option-1 is very hard as you also understand making immediate action manually is very hard and in fact I have tried in any case but could not succeed as expected.

However, this second method worked and I could erase existing code and now I am able to burn my custom boards with 1-Wire, thank you for this wonderful work around.

Now let me see if I swap P0_5 and P0_6 in my code whether I should be able to use my code and burn the new code as well. I will let you know once I test it. 

Thank you and Kind Regards,

Harish

Hi Harish,

Thank you for the reply and for trying our suggestions. 
Glad you were able to perform 1-Wire UART programming for your custom board.
If you found any answer helpful, you can verify them to help others in the community as well.
If you have any other issue, feel free to raise a new ticket.

Kind Regards,
OV_Renesas

Hi OV_Renesas,

I am trying out with my custom board, even though 1-Wire programming works, as of now it is on luck basis as it works("Connect" itself ) 2 or 3 times only out of 10 times when I press RST button. So, I am still trying out to make it work all the times.

I have debug statements that emits data over UART and they may be interfering 1-Wire communication initiation. This is what my assumption, however even I have tried with Blinky HEX file and same I could not succeed all the time. Some, times it says "CRC mismatch":

And some times:

And another attempt immediately after this worked:

So, this is so fragile and could not rely on it completely.

Any more suggestions to make it work all the time. Do I need any Pulll-Down resistor on P0_5 or any other thing that I need to do? 

Once I get a point where it will work all the time, I can confirm and can update here as that will be help full for all as what precautions others should take if ever they face these kind of issue.

Thanks,

Harish

Hi Harish,

Thank you for the reply.
The SST is a Development Tool and we cannot guarantee that it will work 100% of the time. 
I understand the frustration when trying to burn your FW into your board and does not work all the time. 
If you want to rely 100% on a tool for production, we will have to suggest our Production Line Tool Kit.
With PLT you can program and test up to 16 devices at the same time. Please refer on the PLT product page for more information.

Harish said:

Do I need any Pulll-Down resistor on P0_5 or any other thing that I need to do? 

No, you do not need to add any PD resistor on P0_5. 
You could try to work with Command Interface Line. The SST basically is a UI for the CLI.
Please refer on UM-B-083 for more information on the Command Line Implementation. 
You can find all the available commands and examples on how to use them. 

Did you receive the CRC mismatch error while trying to connect or when you tried to Burn your FW into the SPI Flash? 
The FTDI error is probably due to the FTDI module you are working with.

Kind Regards,
OV_Renesas

Hi OV_Renesas,

Sorry for the late reply as I was checking multiple options to make it work but no success yet.

OV_Renesas said:

The SST is a Development Tool and we cannot guarantee that it will work 100% of the time. 

I can understand this is a software application and may have bugs, but not working 80% of the time is not acceptable. In fact, I do not think this tool is the problem as I was using JTAG and this is working 100% with my custom board and even with 1-Wire it was working some times but now almost always coming as CRC error, so some thing else is wrong that the SST tool itself which we are not able to identify here. Once we identify the root cause of the issue SST will work happily without any glitches. I am very hopeful for this.

OV_Renesas said:

If you want to rely 100% on a tool for production, we will have to suggest our Production Line Tool Kit.

I feel this will not solve the problem as we have not identified the root cause of the issue yet.

OV_Renesas said:

You could try to work with Command Interface Line. The SST basically is a UI for the CLI.

I have tried with CLL as well and the behavior is same. This is expected as CLI is just another interface of the SST. And just for information I have tried JTAG interface with CLI as well and it works 100%. Issue is only with 1-Wire interface.

OV_Renesas said:

Did you receive the CRC mismatch error while trying to connect or when you tried to Burn your FW into the SPI Flash? 

The CRC error was coming while trying to "Connect" itself.

OV_Renesas said:

The FTDI error is probably due to the FTDI module you are working with.

I have tried with DevKit Pro as well and the behavior is same, means I got CRC error. So, I feel there is not issue with FTDI module as behavior is same.

Here is my jumper settings and wire connections on DevKit Pro:

Thanks,

Harish

Hi OV_Renesas,

[NOTE: I am sorry, while replying, my reply was not posted and gave messages saying that moderation is required and hence I replied again by highlighting your comments in blue color. And these posts that require moderations will neither post here or nor reach your team unfortunately. This issue I always face on your forum while replying and never solved this]

Sorry for the late reply as I was checking multiple options to make it work but no success yet.

The SST is a Development Tool and we cannot guarantee that it will work 100% of the time.

I can understand this is a software application and may have bugs, but not working 80% of the time is not acceptable. In fact, I do not think this tool is the problem as I was using JTAG and this is working 100% with my custom board and even with 1-Wire it was working some times but now almost always coming as CRC error, so some thing else is wrong that the SST tool itself which we are not able to identify here. Once we identify the root cause of the issue SST will work happily without any glitches. I am very hopeful for this.

If you want to rely 100% on a tool for production, we will have to suggest our <a href="">www.renesas.com/.../da14580prodtlkt-bluetooth-low-energy-soc-16-site-production-line-tool-kit">Production Line Tool Kit

I feel this will not solve the problem as we have not identified the root cause of the issue yet.

You could try to work with Command Interface Line. The SST basically is a UI for the CLI.

I have tried with CLL as well and the behavior is same. This is expected as CLI is just another interface of the SST. And just for information I have tried JTAG interface with CLI as well and it works 100%. Issue is only with 1-Wire interface.

Did you receive the CRC mismatch error while trying to connect or when you tried to Burn your FW into the SPI Flash? 

The CRC error was coming while trying to "Connect" itself.

The FTDI error is probably due to the FTDI module you are working with.

I have tried with DevKit Pro as well and the behavior is same, means I got CRC error. So, I feel there is not issue with FTDI module as behavior is same

Here is my jumper settings and wire connections on DevKit Pro:

Console output:

Thanks,

Harish

Hi OV_Renesas,

Just for information:

I have tried to erase chip and tried to connect it worked and I burned the Blinky could connect and burn the code. After that while Blinky code is running, I could connect and burn as many times as I want that means SST UI mode and CLI mode is working fine.

However, as soon as my code was burnt once, it cannot "connect" and getting  error.

So, there must be some thing wrong in using the UART port. However, as you suggested earlier, I can use UART in my code without impacting but looks like this is not true.

Actually I am not using standard periph_init() to initialize UART but not writing anything to UART on startup, so the communication will not give any problem but UART initialization code exists and not sure whether that will impact or not.

Thanks,

Harish

Hi Harish,

Thank you for the reply.
I have also approved your Answer and it is not visible to everyone. 
I have personally checked, and you are not in the Moderated list, so I do not know why your posts keeps on getting on this list. 
Regarding the CRC error:
The protocol required to establish successful communication and to download the SW image into the RAM is shown in AN-B-072, Table 7, page:31

And the Boot Flow can be seen on the image below:

Since you are able to use 1-Wire UART programming with other FW (blinky) but not with your FW, it is plausible that there is the reason of this issue.
You are only using P0_5 as your UART2 Pin? The pin P0_5 is not being used for any other reason inside your project?
Would it be possible to connect a logic analyzer on the P0_5 and share the capture? We would like to see the initial bytes being transmitted.
Would it be possible to share the .hex file of your project so I could try to replicate this issue on my side? If you do not want to share your project publicly, you can raise a private ticket and share it there. 

Kind Regards,
OV_Renesas

Hi Harish,

Thank you for the reply.
I have also approved your Answer and it is not visible to everyone. 
I have personally checked, and you are not in the Moderated list, so I do not know why your posts keeps on getting on this list. 
Regarding the CRC error:
The protocol required to establish successful communication and to download the SW image into the RAM is shown in AN-B-072, Table 7, page:31

And the Boot Flow can be seen on the image below:

Since you are able to use 1-Wire UART programming with other FW (blinky) but not with your FW, it is plausible that there is the reason of this issue.
You are only using P0_5 as your UART2 Pin? The pin P0_5 is not being used for any other reason inside your project?
Would it be possible to connect a logic analyzer on the P0_5 and share the capture? We would like to see the initial bytes being transmitted.
Would it be possible to share the .hex file of your project so I could try to replicate this issue on my side? If you do not want to share your project publicly, you can raise a private ticket and share it there. 

Kind Regards,
OV_Renesas

Hi OV_Renesas,

Just to conclude on it, as I am NOT able to use this 1-Wire UART programming reliably, even after multiple attempts to fix the issue, I am discarding this approach and looking for an alternative, and hence no more investigation is required here.

Thanks a lot for your continuous support.

Kind Regards,

Harish.