CW-Nano internal target board LEDs

1

Hello,

Since I have the Nano, I noticed every time the target start running both led’s become active.
I was reading the source code and, at least, in basic-passwdcheck.c are several calls to led_ok() and led_error(), but the state of leds didn’t change.

I noticed this when tried to go beyond the tutorial, I wanted to try with a longer password, to make a noticeable difference I added more ‘grabage’ after the password comparison, some delays, some uart messages and some led action…
But leds didn’t work as expedted.

I wanted to find the root of the problem, and found that always a firmware starts it calls the function trigger_setup() among others.
I found this function is declared on the file /hardware/victims/firmware/hal/stm32f0_nano/stm32f0_hal_nano.c but this function is not only setting up GPIO_PIN_7 as trigger pin, it also power on both leds on the target board declared

void trigger_setup(void)
{
	__HAL_RCC_GPIOA_CLK_ENABLE();
	
	GPIO_InitTypeDef GpioInit;
	GpioInit.Pin       = GPIO_PIN_7;
	GpioInit.Mode      = GPIO_MODE_OUTPUT_PP;
	GpioInit.Pull      = GPIO_NOPULL;
	GpioInit.Speed     = GPIO_SPEED_FREQ_HIGH;
	HAL_GPIO_Init(GPIOA, &GpioInit);

	GpioInit.Pin       = GPIO_PIN_4;
	GpioInit.Mode      = GPIO_MODE_OUTPUT_PP;
	GpioInit.Pull      = GPIO_NOPULL;
	GpioInit.Speed     = GPIO_SPEED_FREQ_HIGH;
	HAL_GPIO_Init(GPIOA, &GpioInit);

	GpioInit.Pin       = GPIO_PIN_2;
	GpioInit.Mode      = GPIO_MODE_OUTPUT_PP;
	GpioInit.Pull      = GPIO_NOPULL;
	GpioInit.Speed     = GPIO_SPEED_FREQ_HIGH;
	HAL_GPIO_Init(GPIOA, &GpioInit);
	
	HAL_GPIO_WritePin(GPIOA, GPIO_PIN_7, RESET);
	HAL_GPIO_WritePin(GPIOA, GPIO_PIN_4, SET);
	HAL_GPIO_WritePin(GPIOA, GPIO_PIN_2, RESET); //Chaged to test behaviour
}

If I delete the call to trigger_setup() function, leds never power on. if instead I set as you see in the pasted text, the led_ok is powered off and led_error is on, but no matter what I program on the target’s firmware, my leds never change once the boot of the chip starts…

I modified basic-passwdcheck.c to do this after good password input, because also added password length check, and needed bigger difference between ‘failed or granted access’

                led_error(0);
                led_ok(1);
                my_puts("Access granted, Welcome!\n");
                led_ok(1);
                my_puts("________________________\n");
                my_puts("\n");
                my_puts("\n");
                my_puts("Sistema de venta por correo a tuttiplén\n");
                delay_2_ms();
                delay_2_ms();
                led_ok(0);
                my_puts("Arrancando sistemas....\n");
                my_puts("\n");
                for(int i=0; i<100;i++){
                    delay_2_ms();
                    delay_2_ms();
                    
                }
                led_ok(1);
                for(int i=0; i<100;i++){
                    delay_2_ms();
                    delay_2_ms();
                    
                }
                led_ok(0);
                my_puts("Sistema de venta cargado.\n");
                my_puts("\n");
                for(int i=0; i<100;i++){
                    delay_2_ms();
                    delay_2_ms();
                    
                }
2

Does your code there result in both LEDs being off? You’ve got a bunch of calls to led_ok, but there won’t be enough time between calls for you to notice the change.

3

thanks for the answer, but if you look closely in the code must see that between the calls of the functions led_ok and led_error there is a for loop that delays about half second, so same delay between the output of the phrases in the uart

also I tried several versions of the firmware trying to put leds on like this one, but both leds remains powered off as trigger_Setup is commented:

‘’’
#include “hal.h”
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main(void)
{
platform_init();
init_uart();
//trigger_setup();
led_ok(1);
led_error(1);

‘’’

same if try to power both on or whatever, I don’t understarnd why that two functions didn’t work

the leds will keep allways in same status as trigger_setup() say in hardware/victims/firmware/hal/stm32f0_nano/stm32f0_hal_nano.c

4

hi,

I recorded a video to show what is happening and what I had done to try to understand it

CWNano Targetboard LEDs

sorry for the pronuntiation, i am not very well with the language… I hope you can understand me…

thanks for the help :smiley:

5

If you skip trigger_setup(), you’re skipping the initialization for the GPIO pins, so it’s expected that they won’t turn on. The LEDs are turned on by the setup function, so calling led_ok(1) and led_error(1) won’t do anything. If you’re trying to turn them off, led_ok(0) and led_error(0) will do so.

6

Hello @Alex_Dewar

I already found that two functions are not working properly with CWNano (latest fw version and latest hw version USBC), no matter if you call them with an boolean value ‘0’ or ‘1’ or a ‘true’ or ‘false’ or even ‘SET’ or ‘RESET’, with other platforms this functions led_ok and led_error are declared in other file, so maybe for CWLite, CWHusky or PRO is working as is, but not with CWNano (or at least with mine)

But just fixed it, I made extra functions on stm32f0_hal_nano.c named led_ok_on() and led_ok_off()
In which I call to HAL_GPIO_WritePin(GPIOA, GPIO_PIN_2, SET); and HAL_GPIO_WritePin(GPIOA, GPIO_PIN_2, RESET); respectively

With that extra funcions the leds are working flawlessly (even without calling trigger_setup() as they are also configured in plattform_init() function)

Regards

7

It looks like the led_ok and led_error functions were being #defined in one of the header files. This should be fixed on the latest commit.

8

yes, they are #defined globally on hal.h declared on stm32f0_hal.h and for CWNano declared and defined on stm32f0_hal_nano.c

9

The issue was that they were being defined as nothing. The intention was that the #ifdef would catch the function declaration to catch platforms that don’t have LEDs defined, but #ifdef doesn’t work like that. The original led_error and led_ok calls should work now.

10

ok, nice

so you removed the full #ifndef and changed by:

__attribute__((weak)) void led_ok(unsigned int status)
{
}

__attribute__((weak)) void led_error(unsigned int status)
{
}

I did this change and the orginal functions works!, so mine are useless, forgot the pr!!!

11

Glad to hear that fixed it. Thanks for your patience with this.

12

Good work!

As complete begginer is a little bit hard to know if I received a defective unit, if is the intended work or if it is a bug :wink:

In the moment I saw that platform_init() already initialize leds and trigger_setup() does too the doubs about maybe the led pins on the nano was being used for something related with trigger or with capture idk. that make sense on my head :sweat_smile:

Also found more exercises can be done with the nano under /archive directory, so i’m pretty happy, my unit is OK and there is more practices I can do, Can I ask for more to the world¿?

13

basic-passwdcheck.zip (1.0 MB)

Hello, sice I made the change I noticed something strange, i’m asking on discord, but as maybe it is related to it the change in soe way…

I can tell you i never seen this spike on a graph with this code since am practicing with the nano.

In the zip file there is the firmware souurcecode for the target and the notebook i’m using

If I comment the call to snprintf and my_puts got that sort of power outage (i’m very noob and don’t know how to explain better)

Also looks like for some weird reason if I let that call run, the entire execution grows from 500 traces when the password is ok, to more than 2000 before going idle, if the password is completely wrong the execution last over 180 traces

Can you please help me to find the source of that spike in the traces when I don’t call snprinf?

Traces

14

After modifing the source code for the target I did the same program, but this one doesn’t generate that big cut in the trace when correct password is provided.

I don’t know what was causing that big break in the traces, but the code I removed runs before comparing both passwords, so I shouldn’t be responsible for it… however, the evidence says otherwise, since without that part of the code responsible for rearranging the characters, the power outage does not occur. I am really upset with this situation, not knowing what or why this occurs is really frustrating, especially due to the fact that if it happens in a more complex code it would be practically impossible for me to find the origin of the problem.

Also I don’t find why this deleted code before the actual password comaprision can cause the power outage only when the password is same size and
basic-passwdcheck.zip (3.9 KB)
correct…

int i = 0;
        while (size > 0) {
            siz_passwd[i++] = '0' + (size % 10);
            size /= 10;
        }
      
        siz_passwd[i] = '\0';
        
        // Invertir la cadena
        int start = 0;
        int end = i - 1;
        while (start < end) {
            char temp = siz_passwd[start];
            siz_passwd[start] = siz_passwd[end];
            siz_passwd[end] = temp;
            start++;
            end--;
        }

For people who are curious or want to help me know why this happens, I leave the two target’s source codes, the one that causes the error is the one with the .old extension

15

That is quite weird. If you do want to explore this further, I’d recommend simplifying your example as much as possible, as there’s a lot of things going on in your code. For example, it might be turning the LEDs off that’s causing the drop in power.

16

Thanks for your answer and your help @Alex_Dewar

As far I has investigated there can not be the leds, the outage comes before all led action just after the extract of code pasted and before the if not badpass, and it disappeared when I deleted the preceding part that originally was used to make the int size of the password a char (blame to chatgpt that asked how to transform into to char in c)…
Also when trying to solve I ended with a version of the code without any led on

17

Sorry for the stupid question but I searched among the notebooks and the documentation webpage and don’t find any place where say if is possible and if is that the case how to be able to capture more traces in the same amount of time… I found at Nano’s features page this sentence ADC limited to 20MS/s (can be overclocked slightly, up to 30MS/s but not guaranteed)

At first I thought that maybe it could be done by changing acd.clk_freq or io,clkout values, but changing first had no effect at all (tried few different values between 4.0E6 and 15E6) I got the same exact graph with same number of traces when I was expecting to see half or double signal catched in the graph (as with double clock takes half time to get same amount of samples, isn’t?)… when I tried to change io.clkout I was unable to get any valid data no matter if the value was lower or greater than the original value 7.5E6
If I misunderstood the concept, please tell me, maybe what I’m trying to do is simply impossible :sweat_smile: