Situation:
The DA14683 is running in PRIVATE_CNTL mode (privacy 1.2). We are planning on using the PLT for production programming and testing.
I understand that there are some requirements for specific bit configurations for BLE addresses in some modes, such as: Top two bits set for PRIVATE_STATIC_ADDRESS
I DO NOT want to burn an address into OTP and later find out that it is not valid.
Questions:
1) If we are using PRIVATE_CNTL (privacy 1.2), when using the PLT to assign the BLE address, what requirements are there for the address that the PLT assigns? Do any specific bits need to be set? Said another way, what range of addresses are valid for PRIVATE_CNTL mode operation?
Hi Nathan,
Let me check this and will get back to you .
Regards,
PM_Renesas
Sorry to push, but this is holding up my progress on getting the PLT running. Being Friday, now I won't get any feedback until next Monday. I didn't expect this to be a 15 day question. Am I really the first person to ask what BLE address requirements are for PRIVATE_CNTL (privacy 1.2) mode?
All you need to do in order to enable privacy 1.2, is to see the dg_configBLE_PRIVACY_1_2 to 1 in the custom_config_qspi.h file.
According to own_addr_types structure :
#if (dg_configBLE_PRIVACY_1_2 == 1) PRIVATE_CNTL /**< Private Random Resolvable address using LE privacy v1.2 */#endif /* (dg_configBLE_PRIVACY_1_2 == 1) */
So, the BDA should have the format of Private Random Resolvable address :
Best regards,
Please confirm:
1) Does the PLT input for the BD Address have MSB on the left or LSB on the left?
Say I want the Most Significant Byte to comply with the above rules for Private Random Resolvable so the most significant bits are "01", then all the other bytes to be 0xAA.
First (most significant Byte) = 0b01000000 = 0x40
All other Bytes = 0xAA
In that case is this a valid Private Random Resolvable address, and is it entered in the PLT BD addresses section correctly?
PING. Please confirm, or post the correct formatting.
Ping. I would very much like to resolve this. Please confirm or correct.
Ping again. I'm sorry but I thought this was going to be a quick question. There has been no answer all week. It's Friday now and I won't get a response until Monday at the soonest. Based on previous experiences, there will need to be more support before I get the BLE system actually working after a major change like loading the BD Address from the OTP, but I cant' move on to troubleshooting those issues until I get confirmation that I won't permanently destroy the DA14683 by entering the BD address in the OTP incorrectly. It would be great if this sort of information was documented fully in the PLT manual, but it's not.
Could you please give me a heads up why this isn't a simple question that could be answered quickly? How long do you expect this question to take to answer?
I have escalated this internally to have a look. I'll get the confirmation you need ASAP.
Panos
Nathan.L.Cook said:1) Does the PLT input for the BD Address have MSB on the left or LSB on the left?
I confirm it and the correct answer is : MSB on the left and LSB on the right
Thank you for responding on the weekend.
I will proceed with the left most box in the PLT (most significant BYTE) as 0b01000000 = 0x40, which as you noted should meet the requirements for Private Random Resolvable.
Moving on to the next problem......
Now that I have the BD Address sorted out, I need to write it to OTP.
Under the PLT "Memory Header" tab, and "OTP Header" section there are these options for "BD Address":
The value that is pre-populated in the OTP address section looks unreasonably large.
1) How do I determine what OTP address to burn the BD Address?
2) Does the SDK expect the BD Address to be at some specific OTP memory location?
From here: https://www.renesas.com/tw/en/document/dst/da14683-datasheet?language=en&r=1600766
Table 6:
And from here: https://www.renesas.com/us/en/document/mat/um-b-041-user-manual-da1458x-da1468x-production-line-tool-software-and-hw-v43?language=en&r=1580496
New Questions:
1) So based on this, you really do want me to tell the PLT to burn the BD Address to OTP memory location 0x7F8EA58?
Using the SS Toolbox, I was able to confirm the PLT knows about a "chip configuration section" that has default addresses for system stuff, and that the PLT wrote the BD Address to the right spot passing address 0x7F8EA58.
Reading the value back out of OTP requires some work because apparently no functions were ever added to the SDK for that. (Please check me if I'm wrong here, but I asked in that other thread and no one responded).
https://community.renesas.com/wireles-connectivity/f/bluetooth-low-energy/22607/how-to-get-bd-address-from-otp-rom
This function was simplified because it's always going to be the same address so you can skip the address calculation stuff.
I was able to read the BD Address back out of OTP this way..