Simpleserial2 Inconsistent output and frame byte errors

Embedded Security ChipWhisperer Software
1

Hi,

I am attempting to benchmark between using SSV1 and SSV2 to see which one is faster, I saw that the baud rate is higher for V2 and thought it may speed up my trace collection. The target is the Cw308 + STM32F303 target. I have been able to successfully communicate with SSV1, but have issues with SSV2.

Here, I am trying to write a key and read it back with SSV2:

struct key_str { ... };
key_str my_key = {0};
uint8_t set_key(uint8_t cmd, uint8_t scmd, uint8_t dlen, uint8_t *key)
{
    
    memcpy(&my_key, key, sizeof(key_str));

    simpleserial_put('r', 32, (uint8_t *)my_key.v);
    return 0x00;
}
int main(void)
{

    platform_init();
    init_uart();
    trigger_setup();

    simpleserial_init();

    simpleserial_addcmd(0x01, 32, set_key);
    while (1)
        simpleserial_get();
}

In python, I have the following script:

import chipwhisperer as cw
import numpy as np
scope = cw.scope()
target = cw.target(scope, cw.targets.SimpleSerial2)
scope.default_setup()

and see the following calls:
First, When I reset the target, the write test with simpleserial_write does not work:

image
image2060×235 41.2 KB

However, if I repeat the cell, it works fine:
image
image1755×218 27.9 KB

Second, if I use the send_cmd and read_cmd functions, it does not work at all and gives inconsistent reads.

image
image2234×450 61.5 KB

Have I missed something or am doing something wrong? Why is it so inconsistent?

2

And compiled with:
make PLATFORM=CW308_STM32F3 CRYPTO_TARGET=NONE VERBOSE=1 SS_VER=SS_VER_2_1

3

For your first case, there’s probably just some garbage in the UART buffers from the reset. The start of your read actually has an error code saying that the target received an invalid command.

Your last screenshot has the expected behaviour. read_cmd() just doesn’t extract the data portion of the packet like simpleserial_read() does. If you do target.read_cmd()[3:-2], you should get the same output as simpleserial_read(). I realize now that this isn’t really documented, so I’ll get that fixed up.

If you’re getting inconsistent reads as well, you might also want to increase the delay before trying to read.

4

Ok, that makes sense thanks! Can you explain why the first byte is 0x00 and not 0x72 (‘r’)? Is it the error code?

5

SSV2 is encoded using COBS, which replaces all zeros with the location of the next zero. As a part of that, an initial zero is added onto the beginning so you know where the actual first zero is. You’re seeing the unstuffed packet, so all the zeros have been added back in, including that initial zero.