Part Number: CC2652RSIP
Dear Team;
I want to chage passcode with data which is coming from uart.
Is there any simple project like that?
Best Regards.
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Part Number: CC2652RSIP
Dear Team;
I want to chage passcode with data which is coming from uart.
Is there any simple project like that?
Best Regards.
Hey Oomar,
Can you provide some additional context on your request?
If you are using a Bluetooth LE example such as simple_peripheral, you can follow the code inside simple_peripheral.c and find the SimplePeripheral_processPasscode function. Here you see we have a predefined passcode that is being passed in to the function GAPBondMgr_PasscodeRsp. You can simply replace the define with a dynamic variable that you update with the data from UART.
Keep in mind, the security of the UART channel when it comes to system design will need to be considered here if this is a concern. You are sharing a passcode over UART, and if the UART channel is vulnerable, then there is a potential this vulnerability gets exploited in the connection as well.
Here's a link to our Security fundamentals SimpleLink Academy module, take a look at Task 3.
Additionally, you can visit our User's Guide section on this here: https://software-dl.ti.com/simplelink/esd/simplelink_cc13xx_cc26xx_sdk/5.40.00.40/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/gapbondmngr-cc13xx_cc26xx.html
To change the passcode, you just have to pass in the new passcode as a parameter in GAPBondMgr_PasscodeRsp.
If you want to change the passcode after a device has already paired/bonded with a peripheral, I would recommend disconnecting from the device (as well as removing the bond information locally) to restart the pairing/bonding process with the new passcode.
Hey Oomar,
You can use a pragma statement if you'd like to store variables without NVS. If you need to write, you must place the passcode in RAM and not in Flash. Here's an example, but the address used is placed in flash, so this must be changed: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1004417/cc2650-simple_peripheral-serial-number-using-flash-programmer/3741494#3741494
Otherwise, I recommend using NVS to store the passcode. See this related thread for more details on how to: https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/986551/cc2642r-non-volatile-memory
Hey Ammar;
Are you sure that ram have capable of non-volatile storing.
I writed codes below. When I restarted chip, passcode is erased.
#define APP_SERIAL_ADDRESS (0x400E0000) //AUX_RAM 0x400E 0000 #pragma RETAIN(Psw) #pragma LOCATION(Psw, APP_SERIAL_ADDRESS) uint32_t Psw = 123456;
Best Regards
Hey Oomar,
The address you selected is actually auxiliary RAM used by the sensor controller. See the memory map section of our User's Guide.
The top of RAM is used for the interrupt vector table and TI-RTOS pointers. I would refer to the generated .map file to find an address that works for your application.
Hey Ammar,
.map data are below, I try to SRAM section to save data.
(20000fe0, 200026e9, 200026f0, 20013c00) adresses wil be tried,
When chip reseted, data is ereased.
Any help?
MEMORY CONFIGURATION
name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
FLASH 00000000 00056000 0001ef5a 000370a6 R X
FLASH_LAST_PAGE 00056000 00002000 00000058 00001fa8 R X
RTOS_SRAM 20000000 0000012c 000000e4 00000048 RW X
SRAM 20000fdf 00013021 000028e6 0001073b RW X
SEGMENT ALLOCATION MAP
run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------
00000000 00000000 0001af60 0001af60 r-x
00000000 00000000 0000003c 0000003c r-- .resetVecs
0000003c 0000003c 0001878c 0001878c r-x .text
000187c8 000187c8 0000208e 0000208e r-- .const
0001a858 0001a858 00000144 00000144 r-- .rodata
0001a9a0 0001a9a0 000005c0 000005c0 r-- .cinit
00048000 00048000 00004000 00000000 rw-
00048000 00048000 00004000 00000000 rw- .TI.bound:flashBuf0
00057fa8 00057fa8 00000058 00000058 r--
00057fa8 00057fa8 00000058 00000058 r-- .ccfg
20000100 20000100 0000000c 00000000 rw-
20000100 20000100 00000004 00000000 rw- .data:xdcRomConstPtr
20000104 20000104 00000004 00000000 rw- .data:xdcRomExternFuncPtr
20000108 20000108 00000004 00000000 rw- .data:xdcRomStatePtr
20000fe0 20000fe0 000024e6 00000000 rw-
20000fe0 20000fe0 00001709 00000000 rw- .data
200026f0 200026f0 00000dd6 00000000 rw- .bss
20013c00 20013c00 00000400 00000000 rw-
20013c00 20013c00 00000400 00000000 rw- .stackHey Oomar,
This is expected behavior of saving to RAM, my apologies for not missing this as a requirement.
When chip reseted, data is ereased.
This is precisely what NV is for. Is there a particular reason you do not wish to use NVS? There is an example of this in our User's Guide here: https://software-dl.ti.com/simplelink/esd/simplelink_cc13x2_26x2_sdk/4.40.04.04/exports/docs/ble5stack/ble_user_guide/html/ble-stack-common/flash_memory-cc13x2_26x2.html#id4