MSP432E401Y: ROM Bootloader over UART0 (SLAU746A.pdf)

Hello Marcus,

I will have to try this out. I can try this on Friday and report my results.

Thanks,

Sai

Hi Sai,

thank you. We wait until Friday. In the meantime I did some more tests. Also using UniFlash the behavior is the same. Next I did try to use another serial terminal program to further explore the root cause. While lowering the baudrate to 9600 nothing changes. As you can see from the screenshot. The reply from the MSP432E401Y is as described eralier 0x00 0xCC. Strange.

br

Markus

Some more info for Sai,

I did check the examples in the SDK and yes it shall xmit two octets, the first being 0x00, then the ACK (0xCC). Therefore there is nothing special about it. What is special is the fact, that the answer from the target is not being notified within the UniFlash tool. However the answer is being sent and can be scoped and can be received using another terminal program. Therefore I assume the 'magic' has to do with the UniFlash utility. I am using the version 5.1.0.2397. There is maybe another version that has to be used on the W10 host together with the MSP432E01Y.

The picture below shows part of the UniFlash settings. It is being used in 'verbose' mode showing the two octets being sent from the Host for autobaud recognition. When I try to download the image from the TI-CCS (V9.1...) I get a timeout notification from the UniFlash utility saying no repsonse from the target, the seond image.

br

Markus

Hi Sai,

any news on this topic? We need to be able to download using the delivered ROM BSL from TI. On the target I couldn't not detect a problem. However on the PC-host (W10) UniFlash is not detecting the reply from the target after issueing the sync pattern to the target.

br

Markus

Hi Sai,

thank you for doing the testing. However it does not work. As I did point out in various of my previous posts. I do get the response from the target after the autobaud command. The target is the MSP432E401Y. The BSL-Scripter Tool is saying "No response bytes received from BSL!". When I '"mimic" the behavior of the Scripter-Tool with a terminal program that is able to send binary characters for autobaud recognition the terminal program is able to receive the response from the target. Therefore the signal chain is operating correctly. For the time being I have no idea of what to do next besides starting to debug the BSL-Scripter Source on the PC ...

Hi Markus,

when we send the auto baud rate, the BSL will replay with 0x00 0xCC. I haven't tried the hardware invoke on my end, but the empty device should invoke the bootloader when you power cycle / reset the device.

Could you try to mass erase the device under CCS / IDE that you are using?

Dear Fatmawati Santosa,

you are right and I get the reply you mentioned above as well. I tried to dive deeper setting up MSVS Community Edition in order to debug the BSL-Scripter. I actually find, that the following code never returns. After the timer expires an exception is thrown and the application on the host PC (BSL-Scripter.exe) terminates. Therefore for the moment I am a little despereate, since I can see that the response bytes 0x00+0xCC are in the reception buffer, but since the function is not returning it dies and the program terminates ...

bool UartCommE4xx::waitReceive(uint16_t offset, size_t numBytes) <<<--- never returns ...
{
#if defined (_WIN32) || defined (_WIN64)
    port.get_io_service().reset();

    async_read(port, boost::asio::buffer(&rxUartBuffer[offset], numBytes),
               bind(&UartCommE4xx::onRead, this, boost::asio::placeholders::error,
               boost::asio::placeholders::bytes_transferred));

    timer.expires_from_now(boost::posix_time::millisec(maxDelay));
    timer.async_wait(boost::bind(&UartCommE4xx::onTimer,
        this,
        boost::asio::placeholders::error));

    port.get_io_service().run();
    if (!readError)
    {

    }
    return !readError;

My Command file for the BSL-Scripter:

LOG
MODE E4xx COM16 UART 115200
VERBOSE
RX_DATA_BLOCK_32 blinky_MSP_EXP432E401Y_nortos_ccs.txt
REBOOT_RESET

One more thing,

if I modify the code within of the method calling waitReceive such as it would not be on _WIN32 I get the following and this looks more promissing. Therefore something is wrong within the waitReceive method ...

I expect the author of the BSL-Scripter to fix it asap. I can't do this since I do not fully understand the concept of this code.

Oh it seems that one of the images (VS2017 Debug Session) is missing in the post above. What I made to at least let the BSL-Scripter Tool connect to the ROM BSL target over UART0 was the following. File is UartE4xxComm.cpp line 349 ...

Original (from Github)

std::vector<uint8_t>* UartCommE4xx::receiveBuffer(int32_t size)
{
#if defined (_WIN32) || defined (_WIN64)
    while (waitReceive(0, size)); <<< ---- removed the while loop here, since the return value never returns something to proceed in the code.
#else
    waitReceive(0, size);
#endif

br

Markus

#endif

Dear TI support,

I want you to verify why the method below is written in such a way. In my view this is not necessary since waitReceive itself is blocking until a  timeout occurs or data have been received. For us it is important to have the BSL Scripter up and running for the MSP432E401Y on UART0 using a simple USB2Serial Cable containing an FTDI chip for example. Why is there while loop for the windows version of waitReceive ? (BSL-Scripter source code)

std::vector<uint8_t>* UartCommE4xx::receiveBuffer(int32_t size)
{
#if defined (_WIN32) || defined (_WIN64)
    while (waitReceive(0, size));
#else
    waitReceive(0, size);
#endif

    if (needGetStatus)
    {
        //Send status
        transmitE4xxGetStatus();
#if defined (_WIN32) || defined (_WIN64)
        //Get status
        while (waitReceive(SIZE_ACK_RESPONSE, (SIZE_ACK_RESPONSE + SIZE_GET_STATUS)));
#else
        waitReceive(SIZE_ACK_RESPONSE, (SIZE_ACK_RESPONSE + SIZE_GET_STATUS));
#endif
        //Send host ACK
        transmitE4xxHostAck();
        std::this_thread::sleep_for(std::chrono::microseconds(10));
        needGetStatus = false;
    }
    return &rxUartBuffer;
}

br

Markus

Hi Markus,

Thank you for your patience. I just wanted to leave a note to let you know that we have not forgotten about you and are continuing to find a solution to this issue. 

Thanks,

Seong

Markus,

Thank you for your patience. Please bear with us as we try to provide feedback by the end of this week at the latest. 

BR,

Seong

Hi Markus,

apologized for late response. There are couple of things to be clarified here, this might be a bit long to follow :)

1. When we are using the ROM bootloader, the automatic baud rate is always activated. Therefore the sync-byte should be sent. Host sends the 0x55 0x55 and the target device bootloader replies with 0x00 0xCC. What shown in your oscilloscope screenshot is excepted.
2. However, I found the limitation on BSL Scripter side. When the software is updated, we combined the use with the communication bridge what so called "MSP-BSL Rocket". Since the Rocket supports not only the MSP432PE4 but also MSP430 and MSP432P4. If you take a look into the UartCommE4xx::init() function, BSL Scripter will initialize the baud rate with : (chosen baud rate + 8). This special baud rate is generated so that Rocket knows that it works with E4 devices. Why? Because to work with other MSP430 devices, Rocket has to generate special hardware invocation through other pins. the problem that we saw--which I could reproduce here, mostly caused by the (chosen baud rate + 8) and when it switch to the actual communication baud rate, might be the sync byte 0x55 0x55 is not sent with precise speed.
   
   
3. If you would like to use BSL Scripter, I found a simple workaround that you need to add on the script:
   MODE E4xx COM28 UART 115200
   DELAY 1000 // 1 second delay, shorter could work too, the unit is in milliseconds
   RX_DATA_BLOCK_32 boot_uart_flash_MSP-EXP432E401Y.txt
   the delay will give some time for BSL Scripter has enough time to switch from (baudrate+8) to be the actual baudrate
   
   
4. Or else, we have the bootloader programming functionality using GUI UniFlash, where you can specifically choose the communication bridge that you are using.
   

let us know if you still face problem.

ngrkus,

Any updates?

BR,

Seong

Markus,

Thank you for the update. I will relay this information to our BSL team.

BR,

Seong