Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using cw308t-stm32f3 #224

Open
Catherinecyj opened this issue Feb 26, 2022 · 7 comments
Open

Using cw308t-stm32f3 #224

Catherinecyj opened this issue Feb 26, 2022 · 7 comments

Comments

@Catherinecyj
Copy link

I am sorry to ask here for I am new to this project.

I want to use cw308t-stm32f3 as my experiment platform but I am not clear about the whole board I needed. Is a cw ufo basis board together with a stm32f3 target board just fine or I still need a cw-lite board as well?

@rpls
Copy link
Contributor

rpls commented Feb 26, 2022

Could you clarify it a bit between the three?

  1. Do you want to use the Chipwhisperer Lite as a whole (i.e., the CW-Lite with the fixed 32-Bit Target)?
  2. Do you want to use the Chipwhisperer Lite together with the CW308 UFO with the STM32F3 Target (i.e., the CW-lite with the target end snapped of and connected to the UFO board)?
  3. Or do you want to use the CW308 UFO in a stand-alone manner (i.e., without the CW-Lite)?

Point 1 and 2 should behave the same. Same code, same target, just install the chipwhisperer python library, pick the target and run the pqm4 scripts. For Point 3 you'd need a method of resetting and flashing the target. For that, you could probably adapt a FTDI board, or an ST-Link V2/3 with a serial port.

@Catherinecyj
Copy link
Author

Oh I see that clear for Point 1 and Point 2. But if I want to use the CW308 UFO in a stand-alone manner with a ST-Link V2, is that right that I need to change the communication part (i.e., HAL?) with the function provided by STM32 ?

@rpls
Copy link
Contributor

rpls commented Feb 27, 2022

OK so we don't currently support this type of setup. But the changes aren't that hard.

I assume you have the UFO motherboard with the STM32F3 target plugged in? You'll have to figure out how to connect your ST-Link V2 and serial device to your UFO board. Furthermore, you'll have to figure out how to clock your chip (and adapt the HAL accordingly, but it's a minimal change). I suggest you get a Nucleo Board (any should do), but the STM32F4 Discovery should do as well. They have a ST-Link V2 on board with a 6-Pin SWD connector. You need to disconnect the Nucleo-target board by removing two jumpers to be able to use the on-board ST-Link for an external device (refer to the Nucleo manuals) and then use jumper cables to connect the SWD ports to the appropriate J6 ports on the UFO motherboard (SDWIO to TMS, SWDCLK to TCLK, SWO to TDO, GND to GND, NRST to NRST, VDD_TARGET you can probably leave unconnected). Also connect your serial device (the Nucelo boards have a built-in serial device that you can use!) to the TX/RX on J5 of the UFO motherboard (i.e., TX from Serial to RX on the UFO, and vice versa). Final part is to adapt the clocking setup in hal-opencm3.c. The UFO board is usually geared towards the CW-Lite providing an external clock, and the HAL is using that at the moment. The easiest approach would probably be to use the internal HSI clock on the chip. The HSI is enabled from the start, so it might be sufficient to just remove the clock setup entirely (although I'm not sure if the OpenCM3 lib expects you to at least set the clock frequency variables to the appropriate value). Alternatively, my UFO motherboard came with a 16MHz Crystal that you can plug into X1 on the UFO motherboard, jumper J3 to "crystal", remove the oscillator bypass in the clock setup, and change all the clock values to 16 MHz (or to whatever crystal you plugged in there). If you intend to perform any type of side-channel analysis with the UFO board (that is, with an oscilloscope and not the CW-lite), I strongly suggest you use the crystal option because the HSI is usually a wobbly mess.

The HAL code probably doesn't need any further adjustments beyond the clocking stuff. If you want to use the automated Python scripts of the project, you'll have to define a separate target. But there you can probably just copy what's done for the nucleo-l476rg target on the python side.

I don't have the time right now to give more detailed guidance, but that should set you on the right path to do it yourself. Otherwise, you'll have to wait a few weeks and I can implement this as a separate target (e.g., adding something named like cw308t-stm32f3-standalone).

@Catherinecyj
Copy link
Author

Catherinecyj commented Feb 28, 2022

I am not sure about my understanding.

So if I get a Nucleo Board, I can conncet the ST-Link V2 on it togerther with my UFO board. The Nucleo Board here may work like a communication bridge between PC and UFO board, and in this way I just need to change the clock settings.

But I also see that the ST-Link V2 can plug in J6 on UFO that maybe I don't need a Nucleo Board. Then in this way maybe I need to change more like clock settings and HAL ?

If so, I may considering having a Nucleo Board and I will try myself first. Thank you for your guidance and it will be great help if you can implement cw308t-stm32f3-standalone as a separate target when you have free time.

Thank you so much.

@Catherinecyj
Copy link
Author

For convenience, I have the Chipwhisperer Lite together with the CW308 UFO with the STM32F3 Target. However, when I try to run the testvectors.py with python3 testvectors.py saber -p cw308t-stm32f3, I met with a assertion error.

capture

@37eex9
Copy link
Contributor

37eex9 commented Oct 24, 2023

I just found the cause of this issue. Actually it is not due to this repository but to mupq/mupq.
In platforms.py in line 173 it says :
data = data[:match.end()]
but shoud be
data = data[match.end():]

This fixed it for me and I could verify the correctness of the ChipWhisperer boards.

P.S.: the testvectors.py is absolutely not verbose and makes it hard to debug things like this. (Just to mention it at some place)

@37eex9
Copy link
Contributor

37eex9 commented Nov 10, 2023

This was solved in the mupq/mupq repo as stated in mupq/mupq#116 and the submodule in pqm4 was updated to include this solution.
It should be working now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants