• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 54 subscribers
  • Views 425 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.

Trying to understand Chronos source code for Wireless Update...

dirt road84483
Intellectual 845 points


Hello, I am trying to understand the wireless update of Chronos. Im in the process of modifying this to create a wireless bootloader for our product. Here is what I understood:

1. the Chronos wireless update code for IAR overwrites the existing BSL of the chip.

2. in order for it to update, it will copy the bootloader from the BSL to the RAM then perform the update. However, I am checking the TI-txt output and I can see that addresses @1D30 @FFE0 @FFFE are present. From the datasheet, 1D30 is the RAM. With this, does this TI-TXT file update the BSL? or is that RAM location (1D30 onwards) mentioned are non-volatile (sorry for this stupid question, I am a little lost actually)?

Hoping for some enlightenment. Thanks

@1D30
31 40 FE 2B 3C 40 60 29 3D 40 1A 01 B0 13 46 25
3C 40 52 29 3D 40 C0 1D 3E 40 0E 00 B0 13 16 26
80 00 1A 26 4C 4A B0 13 1C 26 80 00 52 24 3D 40

............ (more data here) .......
69 1D 6C 43 80 00 1A 26 B2 B0 20 00 02 0F FC 2B
10 01 4D 43 4C 43 80 00 1C 26 80 00 12 26 0C 43
10 01 80 00 0A 25 80 00 34 25 10 01 10 01 10 01
10 01
@FFE0
7B 00
@FFFE
30 1D
q

  • 0
    Guru 22270 points

    Hello Dirt,

    Without being too familiar with the Chronos, I would say that the @FFFE address in NV memory is the starting address of the RAM location (RAM_START) and the @FFE0 is the number of bytes to send (RAM_END).  The format that it is stored in is LSB first. So 30 1D is 0x1D30 and 7B 00 is 0x007B.

    Thanks,

  • 0 in reply to Greenja
    Intellectual 845 points

    thanks for the reply.

    I am currently confused because of the following:

    - from the datasheet, the RAM is from 0x1c00 to 0x2bff. and if in case the programmer will load it in the chip, all the code on the 0x1d30 onwards will be lost on reset. but when I try to perform a reset via debugger (MSP-FET430UIF), it seems that there is still some program code on 0x1d30.   maybe it is stored somewhere else before it uploads the code to the RAM?

    - if data will be written on the RAM  (for example the 0x1d30 according to TI-TXT) by the programmer, does it really write it to the location 0x1D30? or it writes it to some non-volatile storage first (for example the BSL area) then the MCU uploads it to the RAM after reset?

  • 0 in reply to dirt road84483
    Guru 22270 points

     The RAM is filled by the program executing in flash.  It writes the data into RAM after reset, where it can then executed from while the flash is being updated. At least that is my understanding of it.

  • 0 in reply to Greenja
    Intellectual 845 points

    greenja said:

     The RAM is filled by the program executing in flash.  It writes the data into RAM after reset, where it can then executed from while the flash is being updated. At least that is my understanding of it.

    thanks for the reply.

    I have the same understanding as well. If this is so, then a TI-TXT with RAM location automatically write it to some non-volatile memory. In this case, I checked the code memory (0x8000) is blank and I presume that it stores the code somewhere else. Is it stored on the BSL area? I can't seem to see the contents of the BSL section  via debugger maybe it is secured.

    Is there a way for me to control where to locate this code (either on BSL or a section on the code memory) before it loads it to the RAM?

  • 0 in reply to dirt road84483
    Guru 22270 points

    Unless you have access to the BSL code, I think you will be unable to change the location. 

    The only possible way would be in your code, write a new address to the FFFE and copy the contents of RAM at 1D30 to the location you pointed to in FFFE.

    Thanks,