CC2642R: Getting Flash fail when we are trying to flash in 1ms task

Hi,

What do you mean by "1ms task" and "2ms task"?

Are you flashing the same FW in both cases (for both tasks, 1ms and 2ms)?

In case you do get the FLASH_FAIL status, can you try to increase the period of your task (e.g. if it fails once on the 1ms task, try to wait 2ms instead, then revert to 1ms after any successful load with 2ms).

Thanks,
Toby

Hi Toby P (5084795),
 

Thanks for your responce ,
 

1ms task means it is a runnable which will be scheduled for every 1millisecond, same for 2ms(  scheduled for every 2milliseconds)
 

Can i know What is mean by FW ?(My understanding is Same Binary)
 

If my understanding is Right ,then yes, I'm trying to flash same Binary for both the cases.

i have one question if we are getting flash_fail then we need to start from PING again or We need to Resend the same packet Again ?

ARUL E said:

Can i know What is mean by FW ?(My understanding is Same Binary)

Yes, by "FW", I mean "firmware", essentially same as "binary".

ARUL E said:

1ms task means it is a runnable which will be scheduled for every 1millisecond, same for 2ms(  scheduled for every 2milliseconds)

Thanks for clarifying. In that case, my suggestion stays the same:

Toby said:

In case you do get the FLASH_FAIL status, can you try to increase the period of your task (e.g. if it fails once on the 1ms task, try to wait 2ms instead, then revert to 1ms after any successful load with 2ms).

ARUL E said:

If my understanding is Right ,then yes, I'm trying to flash same Binary for both the cases.

i have one question if we are getting flash_fail then we need to start from PING again or We need to Resend the same packet Again ?

If you get flash_fail, I'd recommend to send the previous SEND_DATA.

Hi Toby,

 I1)'m trying to reduce the Ti_flashing timing, it is mandatory for me to call Ti_flashing Runnable in 1MS. In 1ms We are trying send the same failed packet again, but we are getting same Return value as (FLASH FAIL). what shall i do?

2)In Our case we set the BAUDRATE as 600000U, Polarity and phase is 1 and 1 with MSB, what is the Minimum time we can achieve with the following the parameters?

3)If we increase or decrease the number of zeros we are sending to Ti, after any CMD then we are not receiving the response. Any idea on this?

For Example: I was sending CRC CMD, after that now i'm sending 8 zeroes to get the response from TI. Now after few failures i'm getting Proper CRC Value from TI chip. Now if i change 8 zeroes to 10 zeroes or 12 zeroes, we won't get the CRC response, Any idea on this? 

Thanks for sharing more details of your investigation.

I will look into and provide an update within 3 business days.

Can you try with a lower datarate?

For example, our spicontroller example uses 1000000.

Please try with different data rates and let us know if those improve.

Hi Toby,For 1000000 it is flashing but While Validating We are getting CRC mismatch Error. For 1050000 FLASH_FAIL we are getting. Any Other values I need to test ?

Any Update on QUESTION  3)If we increase or decrease the number of zeros we are sending to Ti, after any CMD then we are not receiving the response. Any idea on this?

Hi ARUL,

Toby is on a well-deserved vacation until 9/9, so I can try to assist until he returns.

ARUL E said:

For 1000000 it is flashing but While Validating We are getting CRC mismatch Error

This is an improvement.  What bootloader software are you using and how is it checking the CRC?  Even without validation, does the binary run and operate as expected?

ARUL E said:

For 1050000 FLASH_FAIL we are getting. Any Other values I need to test ?

From Chapter 10.2.2 of the TRM: "The SSI interface has a hardware requirement that limits the maximum rate of the SSI clock to be at most 1/12 the frequency of the SSI module clock (48 MHz / 12 = 4 MHz)."  So 6 MHz is not acceptable and 1.05 MHz does not divide well from the SSI module clock, also creating issues.

ARUL E said:

If we increase or decrease the number of zeros we are sending to Ti, after any CMD then we are not receiving the response. Any idea on this?

You will need to use the correct COMMAND_DOWNLOAD_CRC packet format to receive an ACK.  This is detailed in Chapter 10 (along with other Bootloader details) of the TRM.

Regards,
Ryan

Hi Ryan,

thanks for your responce.

 Ryan said: This is an improvement. What bootloader software are you using and how is it checking the CRC?  Even without validation, does the binary run and operate as expected?

To flash TI_chip we are using BACKDOOR bootloader mode, that binary is not running as expected.it is not even booting up.

 Ryan said: From Chapter 10.2.2 of the TRM: "The SSI interface has a hardware requirement that limits the maximum rate of the SSI clock to be at most 1/12 the frequency of the SSI module clock (48 MHz / 12 = 4 MHz)."  So 6 MHz is not acceptable and 1.05 MHz does not divide well from the SSI module clock, also creating issues.

For this i will test with different Values.

 Ryan said: You will need to use the correct COMMAND_DOWNLOAD_CRC packet format to receive an ACK.  This is detailed in Chapter 10 (along with other Bootloader details) of the TRM.

This is not only about Download_CMD ,i mean to say after sending any Packet of Data to TI, to get the response from TI we need to send Zero's, If u increase or decrease that Zero's I'm not getting Response itself.

ARUL E said:

 Ryan said: From Chapter 10.2.2 of the TRM: "The SSI interface has a hardware requirement that limits the maximum rate of the SSI clock to be at most 1/12 the frequency of the SSI module clock (48 MHz / 12 = 4 MHz)."  So 6 MHz is not acceptable and 1.05 MHz does not divide well from the SSI module clock, also creating issues.

For this i will test with different Values.

Thanks, please let us know the result from this test.