• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 52 subscribers
  • Views 491 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2650: simple_peripheral serial number using Flash programmer

Jim Tompkins
Intellectual 350 points
Part Number: CC2650


Hi,

I'm using code derived from simple_peripheral.  I'm trying to write a serial number in the format YYMMDDSSS using the command line interface of the SmartRF Flash Programmer.

I modified devinfoservice.c as follows:

// Serial Number String characteristic
static uint8 devInfoSerialNumberProps = GATT_PROP_READ;
static uint8 devInfoSerialNumber[DEVINFO_STR_ATTR_LEN+1] = "YYMMDDSSS";

built the project and then flashed it.  I can connect over BLE and read the YYMMDDSSS serial number.  So far, so good.  In the SmartRF Flash Programmer, I read out the Flash contents to a file and then searched it to find YY.

There is an unexpected BF byte 4 bytes into the string, and after the "SSS" (0x53 0x53 0x53) there is an unexpected 0x01 0x4F before the expected 0x00.  

What are these unexpected bytes?  Can I simply write the locations where the bytes of my serial number exist?

Thanks,

Jim

  • 0
    TI__Mastermind 42790 points

    Hi Jim,

    I have assigned an expert to help you with your query.

    Best Regards,

    Jan

  • 0
    TI__Mastermind 25810 points

    Hey Jim,

    I'm a bit confused here. You mention you want to write a serial number using the CLI of SmartRF Flash Programmer. Are you trying to change the device serial number to something else?

    The devinfoservice.c is strictly a Bluetooth LE service and it can be populated with any data, using the DevInfo_SetParameter() function. This does not tie to the actual serial number of the device, unless one has explicitly added code to do so. I don't believe it's populated in our examples. Of course, you can assign an extra custom serial number, which I would advise you store in the last flash page in the CCFG section. See here for more details.

  • 0 in reply to Ammar N
    Intellectual 350 points

    Hi Ammar,

    I'm trying to have my own serial number stored in non-volatile memory and readable over BLE.  I don't want to change the BLE MAC address or the factory device serial number, just add my own.

    I looked at the DevInfo_SetParameter.  I guess I could call this function from my code to avoid making changes to devinfoservice.c.  But I'd still have the issue of needing a FLASH area that I can write to at production time, and then the code could copy that info to the devinfo area at startup time using DevInfo_SetParameter.

    I looked at the CCFG but this just seems to be a group of registers to control various things.  I didn't see an available FLASH area described in SWCU117.  Ideally, I'd like to have some code that would declare a few contiguous bytes in FLASH at a known address that I can write to using a cJTAG programmer.

    Thanks,

    Jim

  • 0 in reply to Jim Tompkins
    TI__Mastermind 25810 points

    Hey Jim,

    There's another option to use NV memory space. Read more about it here: Flash — SimpleLinkTm CC13x2 / CC26x2 SDK BLE5-Stack User's Guide 2.02.01.00 documentation

  • 0 in reply to Ammar N
    Intellectual 350 points

    Hey Anmar,

    I think the NV option is for writing from the embedded software.  What I'd like to do is write using the Flash programmer command line (so I can do it in a script at manufacturing time).

    When I write the serial number using the Flash programmer, I get this error if I try to program the application:


    Page to patch (page 31) does not exist in file
    Page to patch (page 31) does not exist in file
    Flash loader reported an error (4)

    Error occured at addr: 0x0001E000, writing 4096 bytes.

    I think this is due to the extra bytes in flash as described above which must be doing some sort of error checking.

    Is there a way I can write a few contiguous bytes in flash using the flash programmer, and then read them in my code?

    Thanks,

    Jim

  • 0 in reply to Jim Tompkins
    TI__Mastermind 25810 points

    Hey Jim,

    I'm sorry for the delay here. After further investigation, using the SNV for writing a serial number is a bit trickier. Do you plan on writing the serial number to flash only once? If this is the case, you can use the final flash page instead of SNV. In this case, I would avoid overwriting the CCFG area. Or will this value be written to very often? If this is the case, it may make sense to use the SNV.

    You should be able to write to the final flash page and use a #pragma to reserve space at a particular address.

    Before attempting to write the area in SmartRF Programmer, it may make sense to attempt the write using the GUI as a quick test first before scripting.

  • 0 in reply to Ammar N
    Intellectual 350 points

    Hi Ammar,

    I plan to write the serial number only once, although to debug the procedure I may need to do it several times.  Thanks for the suggestion on using the GUI first.  

    Can you give me an example #pragma statement?

    What is different about the final flash page compared to the others?  Does it not have the same scheme to store the actual bytes?  Just curious...

    Thanks,

    Jim

  • 0 in reply to Jim Tompkins
    TI__Mastermind 25810 points

    Hey Jim,

    Jim Tompkins said:
    Can you give me an example #pragma statement?

    Here's a quick example. I placed the following code on the top of simple_peripheral.c:

    #define APP_SERIAL_ADDRESS               (0x0001F000)

#if defined(__TI_COMPILER_VERSION__)
#pragma RETAIN(serialNo)
#pragma LOCATION(serialNo, APP_SERIAL_ADDRESS)
#elif defined(__IAR_SYSTEMS_ICC__)
#pragma location=APP_SERIAL_ADDRESS
__root
#endif

const uint8_t serialNo[] = {0xAB, 0xCD, 0xEF, 0xAB, 0xCD };

    Jim Tompkins said:
    What is different about the final flash page compared to the others?  Does it not have the same scheme to store the actual bytes?  Just curious...

    Nothing really, the placement is entirely up to you. The key here is to reserve the space so that it does not get overridden. The key sections to avoid are the SNV space, the RTOS reset vectors, and the CCFG area.