sca201 lab 3_1a does not seem to work with target stm32f071rb

[TotallyNotAStudent0]

Hello,

I was trying to go through lab 3_1a in sca201 the other day, but could not get past the beginning of "Communicating with the Bootloader" : the expected checksum (0xA1) would never show up.

In fact, I believe that the limited amount of RAM on the STM32F071RB is causing a stack overflow which, apparently, is messing with the UART part of the HAL : getch() can only be called once, and any subsequent call to getch() hangs the program. This problem does not arise with the STM32F303RC which has more RAM (48 kB vs 16 kB).

• This works :

int main(void)
  {
    platform_init();
    init_uart();
    trigger_setup();

    // Do this forever (we don't actually have a jumper to bootloader)
    uint8_t i;
    uint16_t crc;
    uint8_t c;
    while(1){
        c = (uint8_t)getch();
        putch(c);
    }
}

• But this does not :

int main(void)
  {
    platform_init();
    init_uart();
    trigger_setup();

  **//Load Super-Secret key
    aes256_context ctx;
    uint8_t tmp32[32] = SECRET_KEY;

    //Load super-secret IV
    uint8_t iv[16] = IV;**

    //Do this forever (we don't actually have a jumper to bootloader)
    uint8_t i;
    uint16_t crc;
    uint8_t c;
    while(1){
        c = (uint8_t)getch();
        putch(c);
    }
}

I tried to determine precisely what in the HAL gets overwritten, but have not been successful in my endeavours.

Respectfully Yours,

TotallyNotAStudent0

[alex-dewar]

Thanks for the bug report! This should be fixed by the latest ChipWhispererer commit (8bf24f6b9f807bfc7b9cea7f0e630132af8fc0eb).

[colinoflynn]

Indeed - this was broken for some time with unknown reasons, your bug report was perfect, so thanks for the details 👍

[TotallyNotAStudent0]

Well, it might not be a stack overflow after all, because even when I (based on your fix) remove everything from the stack like this :

uint8_t tmp32[32] = SECRET_KEY;
uint8_t iv[16] = IV;
aes256_context ctx;
uint8_t i;
uint16_t crc;
uint8_t c;

int main(void)
  {
    platform_init();
    init_uart();
    trigger_setup();

    //Do this forever (we don't actually have a jumper to bootloader)
    while(1){
        c = (uint8_t)getch();
        putch(c);
    }
}

I can't get it to work. This issue is quite mysterious indeed since it looks like it has got something to do with an overflow, and yet I can't believe that the HAL is that memory hungry.

I guess I'll use the STM32F3 from now on since it works flawlessly on that MCU.

Thank you very much for your help

[alex-dewar]

I agree that this probably isn't a stack issue: the F0 and the F3 allocate the same memory (1kiB) for the stack.

Interestingly, the firmware I built for the Nano with the stack change seems to work fine, though in the past I've never seen this firmware work on the Nano.

[alex-dewar]

I'm pretty sure the issue here was actually that I forgot to apply an earlier fix for the getch() function to the non-Nano F0 hal. Basically, if the target misses a UART character, an overrun flag is set. On the F0 only (I believe), this flag being set stops the "new character received" flag from ever being updated, thus making all reads after a missed character fail.

Can you update to the latest git commit and see if that fixes your error?

[TotallyNotAStudent0]

That fixes the issue!

Thank you!