• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 54 subscribers
  • Views 1021 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC1200 AES problem

Evangelos Kaloudiotis
Prodigy 180 points
Other Parts Discussed in Thread: CC1200

Hello,

I am trying to implement AES CTR with CC1200.

I seem to have the same problem as another person in (*). When the first AES is performed, the chip freezes and I cannot transmit a second message. It also seems to cause problems in RX. The first packet is transmitted correctly but after that the chip (CC1200) crushes. It needs a power reboot (not just a reset) to work again. I can tell, because after reset, the initialization of registers  (first thing that happens in the code) freezes, which doesn't happen if i don't perform AES.

In any case, I carefully followed the procedure for AES decribed by Martin B In (*) and paid attention to the notes by chris karvouniaris in the same thread.

Can someone please help?

Regards,

Evangelos

*e2e.ti.com/.../1531956

  • 0
    TI__Guru* 86111 points

    Hi

    Our AES expert is not available this week but he will take a look at this next week.

    In the meantime, please provide as much info as possible on what you are doing in your code to make it easier for us to recreate the problems you are seeing

    BR

    Siri

  • 0
    Prodigy 190 points

    I'm having the same problem that you're describing and that I've seen described on several other threads. I follow all the steps listed in the User Manual to encrypt the TXFIFO, but after I send the SIDLE command to execute AES_TXFIFO, the AES_COMMAND_ACTIVE signal (GPIO0) never goes low. Here are the steps I'm following, and how I verify each of them immediately afterwards:

    -Set radio to Idle (strobe SNOP until status = IDLE)

    -Flush TXFIFO (check that NUM_TX_BYTES = 0)

    -Write packet to TXFIFO (check that NUM_TX_BYTES = packet length)

    -Set AES command (check that MARC_SPARE = 0x09)

    -Write AES key (check that AES_BUFFER_15...0 equals my aes_key_array)

    -Enable direct memory access (check that SERIAL_STATUS = 0x20)

    -Write AES TXFIFO parameters (check that direct memory access 0x3EF0 = 0, 0x3EF2 = packet length)

    -Write nonce to AES workspace (check that 0x3E80...F = my aes_nonce_array)

    -Disable direct memory access (check that SERIAL_STATUS = 0x00)

    -Check to see that GPIO0 is low

    -Strobe SIDLE to execute AES_TXFIFO, wait for GPIO0 to go low

    As you can see, I verify each step after it's taken. I know the SPI interface to the radio is valid because I've been able to successfully configure to several different operating modes and send and receive valid packets with a number of other CC1200s. Any idea why it could be stuck after that? GPIO0 never seems to go low again to indicate AES_COMMAND_ACTIVE is done.

  • 0 in reply to Brenton Graefe
    TI__Genius 12735 points

    Hi Evangelos and Brenton

    We have just released an application report covering the AES operation for the CC1200. You can find it using the following link: http://www.ti.com/lit/pdf/swra483

    Please go through the CTR FIFO example to see if this will solve your problems. If you still have issues please let me know.

  • 0 in reply to Martin B
    Prodigy 190 points
    Hi Martin

    Thanks very much for the application report, it's gotten me past the hanging issue I was seeing.

    I'm now having another issue trying to decrypt the packet on the other end. I'm using Variable Packet Length mode, with PKT_CFG0.LENGTH_CONFIG=0x11, so the 5 LSB of the 1st byte is the length of the packet. I'm sending a packet of length 30 (so byte 0 = 0x1E). However when the CC1200 indicates its received a valid packet and I read the NUM_RX_BYTES register, it indicates I've only received 20 (0x14) bytes. In variable packet length mode, is this register value set by the Length Byte value, which would still be encrypted? Or is it the actual number of bytes the radio has received? For reference, I've had unencrypted variable packet length mode communication working for some time already.

    If this length byte needs to be unencrypted to work in variable packet length mode, is there a way just to leave the first byte of the packet unencrypted? The application report instructs the user to write the pointer to the first entry in TXFIFO to encrypt. Does this mean that I can set this value to 0x01, and it will leave the first byte of the packet unencrypted? Or must it always be set to 0? Additionally, if I don't want to encrypt the whole packet, can I put a length in 0xF2 that is less than the length of the packet? For example, if I have a 10 byte packet, will setting:
    0x3EF0=0x01
    0x3EF2=0x02
    encrypt just the 2nd and 3rd bytes of the packet? Or must the whole packet always be encrypted?