• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 1557 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC2640R2F: Bootloader - different behavior between CC2640R1 and CC2640R2

ROGERG
Mastermind 35360 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: CC2640

Dear Experts,

I have a question regarding the behavior of the bootloader.
We are using the SPI interface to communicate with the bootloader. We are sending a command and then send 0x00 until the CC2640 sends a non-zero response: 0xCC (ACK) or 0x33 (NAK).

This procedure has worked well on CC2640 R1:

But it failed with R2 (the chip did not send any reply):

We do not know why the two chips R1 and R2 behave differently but we found out, that if we increase the timing between two reads while waiting for ACK/NAK it is working.
Before, the timeout was around 5us:

We increased the time to 1ms:

And then the R2 chip did reply to the erase command:

Our assumption is that the frequent SPI interrupts caused by reading 0x00 somehow blocks the chip from performing a proper flash erase. We did not find any restriction regarding this in the TRM or anywhere else.
Thus the question:

What is the suggested time delay for reading the ACK/NAK from the chip?

Is 1 ms ok, or should we increase it? It seems to be working like this but this value is just a random value which we thought would be ok.

Thanks and best regards,

Greg

  • 0
    TI__Guru** 105180 points
    Hello Greg,

    I too am not able to find a specified delay for reading the ACK/NAK in the TRM so I've reached out internally for further input. I will update the post when I hear back.

    Best wishes
  • 0 in reply to JXS
    TI__Mastermind 23440 points

    Hi Greg,

    The developers are looking into it. Could you try different delays and see when it becomes unresponsive? Just to have some data points.

    Also, is the flash erased even if it doesn't respond, or is it not even erased?

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    TI__Mastermind 23440 points

    Greg,

    We were not able to reproduce the issue. As asked in the previous post,

    * When the problem occurs, is the sector content erased even though no response is received?

    Additionally,

    * What other, if any, commands are sent before sector erase?

    Best regards,
    Aslak

  • 0 in reply to Aslak N.
    TI__Mastermind 35360 points
    Hi Aslak,

    I just now received feedback from customer, that it seems they have fixed the issue. It was related to the power supply to the chip.
    They mainly wanted to know, if there is a minimum delay requirement for reading out the ACK/NAK from device?
    If there is not, then they would leave it as it as at the moment.

    Many thanks and best regards,
    Greg
  • 0 in reply to ROGERG
    TI__Mastermind 23440 points

    Greg,

    My information is that there is no delay requirement for when to start polling for the response.

    Best regards,
    Aslak