Device reported error 0x1 when waiting for ack

I am currently trying to get traces from CWlite with the STMF303.

When I try to send the seed for a key to the target board with

target.simpleserial_write(‘k’, seed)

or when I am trying to capture traces as below. Here ‘p’ is the cmd for the encapsulation of the 32 bit plaintext and ‘d’ performs the decapsulation. This plaintext changes for every iteration.

for i in tnrange(num_traces, desc=‘Capturing traces’):
target.simpleserial_write(‘p’, textin_array[i])
target.simpleserial_write(‘d’, bytearray())
ret = scope.capture()
if ret:
print(“Target timed out!”)

I receive the following error:

I’ve tried different variations of sleep and wait_ack but none of them get rid of the error. What else can I try differently?

The issue seems to be with your target communication; error 0x1 means your target firmware received an invalid (unexpected) command: Simpleserial Documentation — ChipWhisperer 5.7.0 documentation

Hi, so I even tested the code separately in gcc and it works there. I am passing seed[64] to the simple serial command and the simpleserial file looks like this:

simpleserial_addcmd(‘k’, 64, get_seed);
simpleserial_addcmd(‘p’, 32, get_ss);


uint8_t get_seed(uint8_t cmd, uint8_t scmd, uint8_t len, uint8_t buf)
uint8_t seed[64];
for (int i=0; i < 64; ++i){
seed[i] = buf[i];
crypto_kem_keypair(seed, pk, sk);
return 0x00;
uint8_t get_ss(uint8_t cmd, uint8_t scmd, uint8_t dlen, uint8_t
uint8_t ss[64];
for (int i=0; i < 32; ++i){
ss[i] = buf[i];
crypto_kem_enc(ct, ss, pk);
return 0x00;

The commands are matching, can you please tell me what the problem can be?

I only have a partial view of your code here so I can’t pinpoint the problem.
We know from the error response that somehow your target is getting an invalid command.
I suggest you break down your capture loop into smaller parts so you can pinpoint which simpleserial exchange is causing this error.

Hi, sorry about that! This is the notebook side of things for both the functions. There is not much else going on in C than the 2 functions and the ‘d’ cmd for decryption. The decryption function does not take any input and uses the keys and the ciphertexts created from the get_key and get_ss functions. Hope that clears up something.

I tried breaking down and getting a single trace. Sending smaller packets of 16 bytes and so on. I’ve also tried different options of timeouts and sleep(). But they throw the same errors.

  1. What is this seed that you are sending with the ‘k’ command
  2. Are you sure that the target baud rate is set correctly? (meaning, unless you’ve made changes that would affect this, 230400 bps with the target clocked at 7.37 MHz)

The seed is the randomness using which I generate the secret key. The key for Kyber is too long, while the randomness is 64 bytes.
For the baud rate, (thanks for that!) I incremented it and reset the scope after every change.

scope.clock.clkgen_freq *= 8 # from 7384615.384615385 to 14769230.76923077
target.baud = 576000 # from 38400 to 76800
Now we have this error. I played with the baud and the frequency but I get either this or Read timed out:


SimpleSerial2 default baud rate is 230400, not 38400:

The serial link might not work reliably at 8*230400; I’d recommend starting with getting it working at 7.37 MHz / 230400 bps before trying a faster clock rate.

Hi, I’ve tried different baud rates, reducing the amount of data sent or received. But I keep getting the same errors except the “Unexpected Frame Byte” error. The minimum baud rate that does not time out is 500000. How can I specifically know what to increase. I inserted a “simpleserial_put” to read whatever the target received (like 16/32/64 bytes of the seed) but it keeps timing out as well.

The problems I have are very similar to the ones mentioned in the post ( Problems in SimpleSerial of project - Embedded Security / ChipWhisperer Software - NewAE Forum), especially towards the end for an unanswered question. A lot of the theory is similar as well.

The simpleserial article is very good, but the errors are only mentioned, is there a resource that mentions what rectifies each of the errors? Thanks!

Trying random baudrates is a waste of time… I suggest you either:

  1. use a debugger to see exactly what your target is doing when it receives your command, and why it thinks it’s a bad command.
  2. go back to one of our stock target firmwares (e.g. simpleserial-aes, though any will do), make sure that works for you, then add some of your new commands to it and hopefully in the process realize the cause of your issues.

It may also be useful to put a logic analyzer on the UART lines, to double check that what’s being sent and received is what you think it is.

There is no other documentation; “invalid command” simply means that the target received a packet with a command field (‘cmd’ below) that it does not know about:
[cmd, scmd, dlen, data_0, data_1, ..., data_n, CRC (poly=0x4D)]