• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 1799 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.

CC430 wireless uploader with BSL

Daniel Berenguer
Expert 2185 points

Other Parts Discussed in Thread: CC430F5137

This is my first contact with the CC430 family and I wonder if there is a way to combine both the provided BSL (serial) and a custom wireless firmloader still to be developed. If I've correctly understood the datasheet, BSL resides in a reserved flash area. I like the fact of having a serial bootloader grabbed by default on the MCU and not interfering with the standard flash memory. The current BSL engine is something I really want to keep but, at the same time, I'll need a secondary wireless loader for punctual remote updates.

AFAIK, my only possibilities are:

  1. Create a custom BSL for wireless and serial uploads, running from BSL memory (2KB)
  2. Keep the current BSL in the reserved region and use an external flash/eeprom memory to store the wireless loader

About 1, do you think that a dual serial/wireless bootloader could be coded in just 2KB?

About 2, is it possible to run code from an external SPI flash or eeprom?

Any other alternative?

Thanks for your ideas!

  • 0
    Genius 3330 points

    I will be following this thread with interest. I just started developing a custom wireless firmware updater for product firmware updates. 

  • 0 in reply to eltury
    Intellectual 845 points

    Hello,

    I am trying to understand the wireless update of Chronos. I have a few questions:

    1. the Chronos wireless update 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. How can 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

  • 0 in reply to dirt road84483
    Prodigy 40 points

    I am battling with this wireless update problem at the moment.

    I want the ability to load an image from an SPI flash chip. The upload to the SPI flash is done in the main program so the BSL is just required to transfer the Image from SPI Flash to the Program Flash.

    I am using a CC430F5137 and do not have easy access to the JTAG port and currently all programming is done via the serial bootloader.

    Questions:

    1.  Will I need to use JTAG to update the BSL or can it be done using the current serial BSL?

    2.  Will 2Kb be enough for an SPI transfer program (I suspect it will, but tight) 

    3.  Which IDE is preferred for BSL programming? Does it matter?

    Thanks

    David

  • 0 in reply to David Haddon
    Intellectual 845 points

    David Haddon said:


    I am battling with this wireless update problem at the moment.

    I want the ability to load an image from an SPI flash chip. The upload to the SPI flash is done in the main program so the BSL is just required to transfer the Image from SPI Flash to the Program Flash.

    I am using a CC430F5137 and do not have easy access to the JTAG port and currently all programming is done via the serial bootloader.

    Questions:

    1.  Will I need to use JTAG to update the BSL or can it be done using the current serial BSL?

    2.  Will 2Kb be enough for an SPI transfer program (I suspect it will, but tight)

    3.  Which IDE is preferred for BSL programming? Does it matter?

    Thanks

    David



    1. what I am doing is using JTAG to update the BSL. but what I think is that MAYBE you can update the current BSL while the application is running (those code at 0x8000 and above). I am not 100% sure but you can try.
    2. I think 2kb is enough. My bootloader code right now is just 998 bytes, that is getting the flash code from the other half of the application code space (upper half excluding the 0xFFxx) of the internal flash and writing it to the 0x8000 code space onwards. The optimization is in the highest level.
    3. the BSL sample code I got is written in IAR from TI's website. As of the moment, I dont know if there is version for CCS.

    using the BSL sample code will help you get started quickly. The code is almost written in a framework style and is neatly partitioned for reuse.

  • 0 in reply to David Haddon
    Guru 227245 points

    David Haddon said:
    1.  Will I need to use JTAG to update the BSL or can it be done using the current serial BSL?

    The serial BSL is not accessible as the two pins used by it (timer CCR0 and CCR1 I/O) are used for other things in the watch and are not accessible.

    David Haddon said:
    2.  Will 2Kb be enough for an SPI transfer program (I suspect it will, but tight) 

    SPI transfer, as it doesn't require tight timing,  should be easier to do (smaller) than a software UART. Also, the replacement 'BSL' doesn't need to support all the commands the original one has, so it can definitely be done much smaller than the original 2k.

    David Haddon said:
    3.  Which IDE is preferred for BSL programming? Does it matter?

    What do you mean? To program the (new) BSL? Or to program the device for the new BSL?
    For the first, an IDE that just uploads the new BSL through JTAG would be fine. Like the Elprotronic software.
    For the second, any tool that supports your BSL is okay. Write it in C++, C#, VBasic, whatever. Maybe even the demo software for your PC/SPI interface may be sufficient. It depends on your BSL implementation.

  • 0 in reply to Jens-Michael Gross
    Prodigy 40 points

    Jens-Michael,

    1.  You have assumed that I am using a watch which is not the case. We have our own wireless sensor node hardware based on the CC430F5137 chip.

    2.  We currently develop application code using msp430-gcc and a text editor and/or XCode. Upload of images is done using a USB/FTDI adapter connected to P1.5 and P1.6 (UCA0) which is a functionality we would like to keep. On the PC side we use a Serial BSL which has been created in python based on code by Chris LiechtiI. Due to past design decisions, there is currently no JTAG connection on the board (I will have to hack this in for testing).  From what I understand, JTAG will be required as the current BSL will not be able to be rewritten by itself?

    3. My question regarding the BSL programming was rewriting the onboard CC430 firmware BSL to allow the same Serial BSL to be used AND the option to load an image from external SPI Flash if a flag is set in INFO memory.

    The BSL code in SLAA450 is part of an IAR project which made me think I should be using IAR. If this is not the case, Great!

    The modular Peripheral Interface idea shown seems great , but what if you need two interfaces?

    I will look into the Elprotronic software.

     

    Thanks for your response.

    David

  • 0 in reply to David Haddon
    Guru 227245 points

    David Haddon said:
    You have assumed that I am using a watch which is not the case.

    Well, almost all request regarding wireless update are using a Chronos Watch. Applications with a separate CC430 are scarce and those that require a wireless update mechanism, well, I don't remember a single one :)

    David Haddon said:
    there is currently no JTAG connection on the board

    The CC430F5137 supports SBW, which uses the same signals (RST/TEST) as the serial BSL does for the entry sequence. So if you cna do serial BSL, you can do serial JTAG (SBW) as well. However, I'm not sure how far SBW is supported on the MSPGCC toolchain you use.

    David Haddon said:
    From what I understand, JTAG will be required as the current BSL will not be able to be rewritten by itself?

    You can upload a program through BSL and start it from within the same BSL session. Then (and only then) the program would be able to update the BSL area. So updating the BSL through BSL is possible. But of course, this ill brick the chip if something goes wrong with the update. (so JTAG/SBW is a bit safer, but you can still accidentally blow the JTAG fuse and lock yourself out completely)

    David Haddon said:
    My question regarding the BSL programming was rewriting the onboard CC430 firmware BSL to allow the same Serial BSL to be used AND the option to load an image from external SPI Flash if a flag is set in INFO memory.

    If you can fit it into 2k memory...
    Well, if you remove all BSL functionality except the minimum required (like no memory read etc.), it should be doable. Unless you need to implement a FAT file system or something like this (to read a file from an SD card). It could be tricky to fit all this into the 2k BSL flash area then. Reading a binary image from raw SD card sectors should be no problem.

  • 0 in reply to Jens-Michael Gross
    Prodigy 10 points

    Hi,

    I would be interested if you have made any progress in developing this Serial/SPI Flash BSL? This is exactly what I would need as well for an OTA service I have in mind for our wireless sensor node software. Would be very nice if you could share your experience or even code such that I do not have to reinvent the wheel.

    Best regards,
    Tonio

**Attention** This is a public forum