CW-Lite Notduino troubleshooting


#1

I cracked apart my CW-Lite, and was still able to run through the example attack with the XMEGA target. But the notduino board doesn’t work without detailed config, so I’m documenting that here in case anybody else is confused by that.

Problem: The red LED goes on, but other than that the notduino is completely unresponsive to both serial commands and either the CW-Lite AVR programmer (once that menu option magically appears under “Tools”) or an external programmer.

Cause: The CW-Lite’s default output clock is not sent to the notduino. Even if it were, it’s set to 192MHz - way too high for the Atmega328P chip, which has a maximum of 20MHz.

Solution: To set up the scope, start off in general settings, and select ChipWhisperer/OpenADC. Then go to the scope tab, and set connection to ChipWhisperer Lite. Now go down to CLKGEN settings. The desired frequency is 3.3MHz which is a lie, so click there and then use the up arrow then the down arrow to really set it there. You’ll get multiply/divide settings of 8/233. Alternatively, set it to 20 MHz (you’ll have to write that in as it’s not a default) and get 5/24. Now go down to CW Extra below, and set “Target HS IO-Out” to “CLKGEN” and you’ll finally get a clock signal going to the notduino.

I guess the long term solution here is to write more example scripts that cover these kinds of settings. Or have a “load script” option so that the community can share them without having to put them in the main chipwhisperer directory. Anyway, I hope this helps somebody.


#2

Hello,

You are way ahead of where I thought people would venture too, so it’s not too well documented yet :wink:

I was working on a demo script today. Should be able to upload a quick example tomorrow with any luck, and will get you rolling with that.

Right now the issue is you need to program the AVR. The CW-Lite has a built-in AVR programmer, but it requires some fiddling to get working with the “virgin” chips. Basically it runs too fast, so there’s a work-around right now to slow the speed down. It will eventually be fully fixed, but at least this should let you get started with the NOTDuino.


#3

As promised, here is some very quick documentation/notes on getting the NOTDuino programmed. Will try to update this shortly / add to main documentation!

Programming AVR (First-Time)
In order to program the AVR the first time, we need to slow down the SPI clock. This requires re-programming the SAM3U device, as the default operating speed of the SAM3U is too fast to allow generation of a slow enough SPI clock. This slowed-down version of the SAM3U cannot be used for data capture. Future releases of CW will include updated SAM3U firmware to allow dynamic adjustment of the main processor speed.

For now use the following steps showing the first-time programming instructions:

  1. Unzip attached file somewhere.
  2. Program the SAM3U with the file NAEBUILD_SAM3U_CWLiteFW_12MHz.bin (in attached zip-file). See Appendix A instructions for details.
  3. Start CW-Capture software.
  4. Select “ChipWhisperer/OpenADC” under “Scope Module” on “General Settings” tab
  5. Select “ChipWhisperer Lite” under “connection” on “Scope Settings” tab
  6. Go to “Tools–>Config CW Firmware”
  7. Switch to “Debug” mode. This will require you to specify a .bit file. Use the attached .bit file (in zip-file) called “cwlite_s6lx9_old_avrprog.bit”
  8. Close that dialog.
  9. Hit the “Scope Connect” button.
  10. NB: The red LED should be very slowly flashing near the FPGA. This confirms you have loaded both the slower-clock SAM3U code and FPGA code.
  11. Select “Tools–>CWLite AVR Programmer”
  12. Hit “Check Signature”, hopefully it reports finding a Mega328P. If you look in the “Debug Logging” of the main window it will print errors there.
  13. Specify the simpleserial.hex (also in zip-file) attached as the FLASH file
  14. Hit “Erase/Program/Verify FLASH”
  15. Hit “Read Fuses”
  16. Change the LOW fuse to D0.
  17. Hit “Write Fuses”
  18. At this point the AVR will stop responding to future commands, as it now requires an external clock source.
  19. Close the AVR Programmer dialog.
  20. Select “Tools–>CWLite AVR Programmer”
  21. Change back to “Release” zip-file.
  22. Close CWCapture main program.
  23. Reprogram the SAM3U with the NAEBUILD_SAM3U_CWLiteFW.bin in attached zip-file.

Note that is only required to set the AVR fuses. In particular one of the fuses is a “divide by 8”, which forces the AVR to run at 1 MHz. At this frequency you cannot use too fast an SPI clock for programming. Now that you have cleared that fuse, you can program directly from the GUI without reloading the SAM3U or changing it’s clock frequency.

Running NOTDUINO
Copy the attached file “cwlite-simpleserialnotduino.py” to “chipwhisperer/software/chipwhisperer/capture/scripts”

  1. Start ChipWhisperer-Capture software.
  2. There is a new “AES SimpleSerial on ATMega328P” option now.

Programming AVR (Future Times)
NOTE: As a temporary work-around, you still need to change the FPGA bitstream. This will be fixed in the next release. But for now you must follow these steps:

  1. Start CW-Capture software.
  2. Select “ChipWhisperer/OpenADC” under “Scope Module” on “General Settings” tab
  3. Select “ChipWhisperer Lite” under “connection” on “Scope Settings” tab
  4. Go to “Tools–>Config CW Firmware”
  5. Switch to “Debug” mode. This will require you to specify a .bit file. Use the attached .bit file (in zip-file) called “cwlite_s6lx9_old_avrprog.bit”
  6. Close that dialog.
  7. Run the “AES SimpleSerial on ATMega328P” script. This will setup an external clock for the ATMega328P.
  8. Run the AVR programmer dialog as usual.
  9. Go to “Tools–>Config CW Firmware”
  10. Change back to “Release” zip-file.
  11. Close CWCapture main program.
  12. You can now re-open the CWCapture program and run the script to re-connect.

APPENDIX A: How to Program SAM3U

  1. Download and install BOSSA. For example select bossa-1.2.1.msi from sourceforge.net/projects/b-o-s-s-a/files/1.2.1/
  2. Using tweezers, short the “ERASE” jumper JP2. When you do this the blue LED will stop blinking.
  3. Unplug and replug the USB device. It will now be detected as a new device, and D1 and D2 will be only dimly lit.
  4. Start BOSSA. Under the “Serial Port” option hit “auto-scan”, hopefully it detects your device. If not it might take a few mins for Windows to install the drivers.
  5. Select the .bin file to program in
  6. Hit “Write”, and then “Verify”. To restart the new software on the SAM3U just unplug/replug the cable.

NOTE: The SAM3U has a ROM-resident bootloader. Thus you don’t need to worry about erasing the device, as you will always be able to reload a new firmware image. If things aren’t working it might be a driver issue, but it won’t be a permanent fault.
notduino_workaround.zip (108 KB)


#4

Colin,
Thanks for the update. I completely understand about the documentation - you delivered the hardware at least a month early, so it makes sense that the docs would lag!

The SAM3U firmware was never a problem for me, so I’ll pass on that for now. I can write fuses and erase/write/verify from the stock SAM3U firmware and the stock FPGA configuration. The hardest part was getting the menu option to appear!

Looking at the fuses, it seems that an lfuse of 0xf0 will work with the CW-Lite but not when plugged into an arduino uno with an external programmer - for the latter you need an lfuse of 0xff. The CW-Lite’s programmer can write fuses in either case, but my Pololu programmer won’t talk to an 0xf0 chip when it’s in the arduino. It’s pretty easy to change the fuse before you pop the chip, but just as easy to forget! The efuse values I’m getting from the CW-Lite are different from what I see in avrdude, because the latter masks out the top 5 bits, but that’s no biggie.

Anyway, by popping chips between the arduino and the notduino, I was able to finally get a simpleserial program that correctly outputs to the UART on the arduino at 16MHz. Oh, and for anybody watching this thread, you need to set the F_CPU in the makefile to match the “desired frequency” from the scope settings, or the serial signal will come out at the wrong speed - obvious once you see it, but easy to forget. Anyway, I did all that, got it working, changed the lfuse to 0xf0 and moved it to the notduino, and it still didn’t work.

In steady state, the TX line from the notduino is at 3.36V. When I hit reset, it goes up to 3.48V. When I release reset, I expect to see the bits for “hello” go over this line, varying between 3.36V and 0V, but while I see those bits go over, the signal is between 3.36V and 2.52V, which is strange. So I disconnected the target I/O connector, and reconnected pins 2, 3, and 6 individually (GND, 3V3 and CLK) - now I get the expected serial output from the notduino, and (remembering to use my 3V3 serial cable instead of the 5V one I have for the arduino) I can finally talk simple serial to the notduino. I guess this is good practice for attacking a component that wasn’t designed to be attacked!

With this in mind, I tested the resistance between FPGA-TARG2 and 3V3 and found 24.1ohms. Is that pin of the FPGA configured for a pull-up resistor, or is this just my board?


Help needed with CW304 Notduino Target
#5

Hello,

The FPGA pin doesn’t have a pull-up… but from the GUI you can configure what the use of the TargetIO pins is. By default this is TX or RX - you can switch them to High-Z to confirm it floats the pins. The NOTDuino script should set it as RXD (input) which shouldn’t load the pin. Note the XMEGA and NOTDUINO targets swap the RX/TX pins (i.e. TARG1 = RXD for XMEGA, but TXD for AVR). This is a bit of a “legacy” thing, as on the Multi-Target board the AVR and XMEGA were configured to allow them to talk to each other… which meant the interconnected TX/RX lines. Which meant when connecting them to the CW the TX/RX were on different pins.

At this point I stuck with the “legacy” convention, I don’t know which would have been less confusing! But it does mean if you load the XMEGA script as a starting point it will configure the IO pins wrong. You can swap them in the GUI, or the script I posted should do that too.

Regards,

-Colin


#6

Colin,
Yes, that was it! I did briefly look at the atmega script you uploaded, but didn’t notice that the pins were reversed, so I kept going with my own script, which as you guessed was derived from the XMEGA one.

By the way, if you’re able to upload the schematics for the notduino and the targio-breakout boards, that’d be very helpful. I notice that there’s a doubled up 1x10 pin header (JP5) on the targio-breakout board, with a different pinout to a very similar 1x10 JP5 header on the CW-Lite. Are they for connecting to anything in particular, and is the difference another of those legacy issues?

Thanks for all the support.


#7

Oops… I meant to add schematics, let me do that ASAP! Everything should be posted, basically if you don’t find it online, I forgot to upload it :wink:

The 1x10 header is different for no good reason basically. The 1x10 on the breakout board (actually full thing is 1x12, but can just use 1x10) was designed for connecting external targets. The 1x10 on the CW-Lite is designed to duplicate the pins to make probing easier. i.e. if you have the 20-pin male header mounted, you might want to probe the IO pins with your scope. The 1x10 on the CW-Lite makes it easier to do that was the idea. Of course it could be used for fly-wire connections or anything else!


#8

I’m good up until this point. It appears that simpleserial.hex was not included in the attached zip! Am I missing something?

Also an FYI for those running 64bit windows - the BOSSA release may be problematic for you. I extracted the binaries after the installer failed, but they were unable to flash. You might want to test that the installation goes smoothly before shorting the JP2 jumper, as you wont have an easy way to recover otherwise. I ended up using my Mac to run BOSSA, but otherwise would have been SOL.

EDIT: I found some instructions for building simpleserial: newae.com/sidechannel/cwdocs/ins … le-targets
However, the WinAVR build tools also seem to be unfriendly to Win8 64bit :frowning: Maybe I’m better off just getting my environment setup in a linux vm?


#9

Hi Jason,

Hmm… I’m using Win7-64. I assume you are running Win8-64? Will test that! There is also another option (the official Atmel tools) that you can use, but they aren’t as user-friendly. I’ll include instructions for using them, as they might work on Win8-64.

Did you add the DLL fix? I’ve been using on 8.1 x64 without problem.

I’m in the process of making a Linux VM as well with everything setup. I was away last week for ESC so didn’t have time yet, hopefully this weekend.

I’ve included the .hex file here anyway as an attachment - must have forgotten it sorry!


#10

Thanks Colin! I’m still unable to see the attachment - is the forum preventing certain attachments based on file extension?

Yes, I was using Win 8.1 Pro 64. No crazy intrusive AV or anything - out of the box install for the most part.

When installing BOSSA (bossa64-1.2.1.msi), it starts off fine and even makes it past the UAC security prompt and starts copying files. However it concludes with a dialog stating:

BOSSA 1.2.1 Setup Wizard ended prematurely because of an error. Your system has not been modified. To install his program at a later time, run Setup Wizard again.

No more detail is given and the installation target path doesn’t exist. Strange… I then tried opening the installer as an archive with 7zip and extracting the binaries manually. There appears to be a bossa.ini driver config file, but no driver signature, which I think may be part of the problem.

Regarding WinAVR, yes I tried the DLL fix and it didn’t change the behavior. When i attempt to make avr-serial, I get the following console output:

C:\chipwhisperer\hardware\victims\firmware\avr-serial>make MCU=atmega328p 0 [main] sh 16244 sync_with_child: child 15916(0x160) died before initialization with status code 0xC0000142 157 [main] sh 16244 sync_with_child: *** child state waiting for longjmp /usr/bin/sh: fork: Resource temporarily unavailable 0 [main] sh 6800 sync_with_child: child 16096(0x168) died before initialization with status code 0xC0000142 388 [main] sh 6800 sync_with_child: *** child state waiting for longjmp /usr/bin/sh: fork: Resource temporarily unavailable rm -f simpleserial.hex rm -f simpleserial.eep rm -f simpleserial.cof rm -f simpleserial.elf rm -f simpleserial.map rm -f simpleserial.sym rm -f simpleserial.lss rm -f objdir/*.o make: *** [clean_objs] Error -1073741502

At this point, I get an Application Error dialog from rm.exe stating:

The application was unable to start correctly (0x00000142). Click OK to close the application.

Is WinAVR based on cygwin? Feels that way. Any luck with avr-gcc or amtel’s toolchain?

Anyway, I did get it to build using WinAVR, even though its not pretty. The forking errors above can be ignored, apparently. First crate the ‘objdir’ subdir, then modify the makefile and edit the clean_objs macro. Comment out the lines that rm objdir/.o and objdir/.lst. For some reason this is causing rm.exe to fail fatally. This allows the build to continue, but then fails when trying to access the non-existant .dep subdir. Just mkdir .dep and try again.

In sort, after editing makefile, do this:

mkdir objdir mkdir .dep make MCU=atmega328p

Worked for me, anyawy :slight_smile:


#11

Also step 20 in the instructions you posted: i believe you meant to say ‘Go to “Tools–>Config CW Firmware”’

Otherwise, seems to be working!


#12

Sorry for posting in an old thread but I can’t seem to find the schematic for the targio-breakout board.
Can you please point me in the right direction?


#13

As of 3 minutes ago, these are now in the ChipWhisperer repo - see https://github.com/newaetech/chipwhisperer/tree/master/hardware/tools/breakout.


#14

Thank you :smiley:


#15

I’m having trouble programming a new notduino board. Is there any update on how to do this?

thanks,
ken