Chipwhisperer husky programming with 20 pin headers attached to it

1

I am running the TVLA script given in the jupyter notebook after making appropriate changes such as having the stm32l4 folder in it’s right position

It made the .hex file but on running program_target it is stuck for a long a time with no output

What could be the possible reason for this problem?

1774418154910361102304711085777
17744181549103611023047110857771920×1446 508 KB

2
  1. Which specific notebook or script are you running? I’m assuming it’s something in the sca203 folder, but there are several there.
  2. Have you successfully used this STM32L4 target with any of our other course notebooks?
  3. Have you successfully run any of our notebooks with another target (e.g. our SAM4S)?
3

I’m running the sca203 - introduction to TVLA notebook

I haven’t used this target anywhere else before

I have successfully run this same notebook on SAM4S

4

Did you set the PLATFORM variable to CW308_STM32L4? Does the firmware compilation run cleanly?

5

Yes it ran cleanly no errors whatsoever

6

…and is there any output at all when you run program_target()?
Can you try it with additional logging by setting:
cw.target_logger.setLevel(cw.logging.DEBUG)

7

Based on the history on this forum, most of the time the problem comes from a bad solder joint on the CW312 to CW313 adapter board :slight_smile:

8

Good point: have you checked connectivity?

9

The connectivity is perfect from what i checked, i will attach the picture in due time as well as try the logging function you mentioned and send those outputs as well

10

so the cause of the problems was that the breakout board became kinda heavy due to the addition of the headers and then the stm chip onto it , putting a bit of support beneath it allows for recognition and programming , with the following output in program_target

Detected unknown STM32F ID: 0x435
Extended erase (0x44), this can take ten seconds or more
Attempting to program 8247 bytes at 0x8000000
STM32F Programming flash…
STM32F Reading flash…
Verified flash OK, 8247 bytes

now i just want to know how significant of a power trace difference is expected between the sam4s and this stm32l4 board , because the traces of stm seem very crowded in contrast with the sam4s

11

Good to know, I’m happy that it works for you now.

This is absolutely what you should expect; the opposite would be very surprising. Both of these targets contain ARM Cortex M4 processors, but the actual arrangement of transistors that implement these processors on your chips will be totally different for several reasons:

  • STM and Atmel could be using different releases or configurations of the Cortex M4
  • they could be using different “compilers” to translate the Cortex M4 source code into gates (in the hardware world these are called synthesis and place+route tools)
  • they could be using different technology libraries (transistor size, fabrication plant)
  • their implementation is likely subject to quite different restrictions (die size, other peripherals competing for die area, power restrictions, maximum clock speeds, etc…)

I could go on, but you get the idea. If you’re totally unfamiliar with the world of silicon fabrication, the simple analogy is this: just as you wouldn’t expect two different compilers to produce the same output from the same source code, you shouldn’t expect Atmel and STM to produce two Cortex M4 cores that have the same power traces.

And on top of all those hardware aspects, there is still potential variability on the software side: how your compiler decides to translate the C code to the machine code can vary a lot. These two targets have different HALs, so obviously the compiled firmware will differ.

12

Thank you for your time and the information, appreciate it a lot