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.

BSL Buffer size for large code files

Other Parts Discussed in Thread: MSP430BT5190

Hi,

We have custom BSL developed for MSP430BT5190. The MSP430 in our design communicates to a custom hardware over UART  and the same hardware we use both for the application and BSL programming. Due to this reason we are not able to use the default timer based UART port for BSL programming.

We face the issue with BSL scripter. Even basic commands like getting BSL version does not work. We hope the issue is with the different UART port we use. We are able to communicate to the BSL with other serial communication tools like hyper-terminal and hence we plan to use such serial communication tools for programming the device via BSL.

Now if we have to send a code file greater than MAX_BUFFER_SIZE (which is = 260) with the serial communication tool, it gives the error 54 (maximum buffer size exceeds).

Can anyone tell how the large code files are sent to BSL by the BSL scripter without exceeding the maximum buffer size? Also any inputs to do it by common serial communication tools are appreciated.

  • I guess that you are customizing slaa450 Creating a Custom Flash-Based Bootstrap Loader (BSL) code. If you are making your own micro side BSL, than also PC side can be redone with support just for few needed functions, some sort of simple version with user friendly interface. In slaa450 is used block write, and writing is done by flushBuffer function in Custom_BSL_Zip_File\5xx_6xx_BSL_Source\API\BSL430_API.c file. There are plenty of spare time during block write (of course, if it is executed from target device RAM), that can be used for updating UART circular buffer, and practically buffer can be unlimited in size, because block write is much faster than UART (at 115200 bps).

    Maybe you have problems with default TI BSL PC side due parity or some other thing regarding UART setup, so terminal tool is working OK, but default BSL is failing.

  • You can use both, BSL timer UART and application hardware UART, on the same connector. If the BSL is entered, the hardware UART is not activated and the pins are high-impedance. If the application is started, the timer pins are not activated for software UART and are high impedance.  Of course this means you cannot use these timer pins for anything else in your application. So both ways can co-exist on the same RX and TX signals..

     However, code sent to the MSP though the BSL is usually sent in chunks. You don’t send the full firmware in one block. You send it chunk by chunk and the BSL puts it into the individually given destination locations. E.g. to put 1k to 0x1000, you tell the BSL to put 256 bytes to 0x1000, the next 256 bytes to 0x1100 and so on. Each one with a separate command.

    Since no MSP has more ram than flash, this is the only way you can send a firmware that is larger than the ram, as the buffer size can’t be larger than the available ram.

  • Jens-Michael Gross said:

    Since no MSP has more ram than flash, this is the only way you can send a firmware that is larger than the ram, as the buffer size can’t be larger than the available ram.

    All existing MSP430 FET's are working on this way, and BSL too. But, this is not the only possible way for sending firmware. With my flasher, complete firmware is sent from PC at once, not in chunks.

  • zrno soli said:
    All existing MSP430 FET's are working on this way, and BSL too.

    They sure do. But if you’re doing it with a whole bulk transfer, then you shouldn’t have to deal with ‘block size exceeded’ errors. Since a bulk transfer mechanism has no block size. Or it wouldn’t be a bulk transfer.

**Attention** This is a public forum