Hi,
We've encountered some problems with Msp430 bootloader mode.
Here are some brief descriptions of our application.
According to our hardware architecture, DSP(F2838x series) is an I2C master and Msp430 is a slave.
Under certain circumstances, the Msp430 is working as BSL mode, so we want to let DSP know the Msp430 BSL core commands in order to control the Msp430 FRAM.
In our DSP I2C structure, the Rx packet length is a defined parameter whilch is varied with the command.
However, we find something tricky is that Msp430 response packet length varies with the condition of "before Rx password" or "after Rx password".
Take core command TX BSL version as an example.
If we use this command after Rx password is unlocked, we will get 5 data packets( CMD+ D1 + D2 + D3 + D4, grey part below ).
On the other hands, if we use this command with Rx password locked, we get 2 bytes data for core response and message instead of 5 bytes data.
The Rx packet length, which is set in DSP I2C, is predefined for the locked scenario. That is, 8 Bytes Rx packet length is what we expect.( Ack + Header + Length1 + Length2 + Core Rsp + Core Msg + CKL + CKH )
Here's the problem,
If we execute the Tx BSL version command twice after the Rx password is unlocked,
The first time we can get a complete communication process end with a NACK and STOP condition.
The second time we find the communication failed when write second data byte to slave.And the SCL is stalled by the Msp430 I2C.
Is this because we assert NACK + STOP when there are still some unsent bytes? if yes, does it mean we must read all the bytes or the SCL will be stalled by Msp430 I2C?
Is there any explanation for the mechanism?
Here's problem 2,
Is there any method we can revert the BSL back to a locked condition?
Thank you.
