Programing the CW308 with target LPC55S69

Hello,

I am trying to use the target LPC55S6X with a Arm Cortex-M33 on the ChipWhisperer Pro UFO Board (CW308_LPC55S6X).

When using the jupyter notebook interface, we usually do something like:

prog = cw.programmers.STM32FProgrammer # or XMEGAProgrammer, etc.
cw.program_target(scope, prog, firmware_path)

But for the LPC55S6X, I do not see which programmer I should use among those available. Is there any tutorial with this target board that I missed?

Besides, I use the same UFO board configuration as the one I used for the STM32F3 target (which is detailed below), as I did not find information regarding this target. Please let me know if anything is incorrect.

J3           : HS2/OUT
J1-VREF      : J1-3.3V (left)
EXT-DC SWITCH (bottom-left switch) : AUTO S1 (left)
J14          : FILT / FLIT_LP-FILT-HP : left
3.3V SRC     : J1/CW (up)
VADJ SRC     : 5V (down)
1.2V LDO SRC : J1/CW (right)
1.8V LDO SRC : J1/CW (right)
2.5V LDO SRC : EXT-DC (left)
3.3V LDO SRC : EXT-DC (left)
5V LDO SRC   : EXT-DC (left)

Thanks,
Quentin

Hi Quentin,

You’ll need to use an external JTAG programmer for that target. I haven’t programmed that target personally, but anything that works with OpenOCD should be able to do it.

As for board setup, it should be pretty similar to the F3. The only major difference is that this target requires a 1.2V VCC, meaning you’ll need the 1.2V LED to be illuminated on the CW308.

Alex

Hi Alex,

Thank you for your reply.
I am not familiar with JTAG programming. I have looked around a bit, and still have some questions. From what I understand, the steps are following (using mainly this page):

  1. On the CW308, use jumper wires to connect the following pins:
    J5 Pin 12 (SCK) → J8 Pin 6 (J_TCK)
    J5 Pin 18 (PDID) → J8 Pin 5 (J_TMS)
    J5 Pin 13 (MISO) → J8 Pin 4 (J_TDO)
    J5 Pin 14 (MOSI) → J8 Pin 3 (J_TDI)
    (source: here)

Question: the tutorial states that these connections are for the STM32F3 board; are they the same for any board using JTAG, in particular the LPC55S6x?

  1. Run the following commands:
import chipwhisperer as cw
scope = cw.scope()
scope.enable_MPSSE(1)
  1. Create a file myconfigfile.cfg with the following content:
source [/path/to/cw_openocd.cfg]
transport select swd
ftdi vid_pid 0x2b3e 0xace3
source [target/lpc55s6x.cfg]

Question: is 0xace3 the correct ProductID to put in that file? (I found it here)

Question: where can I get the file lpc55s6x.cfg? I did not find it neither in the chipwhisperer.git nor in the openocd provided files.

  1. Run openocd -f myconfigfile.cfg

  2. Create a file load_firmware.cfg with the following content:

init
targets
halt
flash write_image erase /path/to/fw.elf
flash verify_image /path/to/fw.elf
reset run
shutdown
  1. Run openocd -f load_firmware.cfg

  2. After loading the firmware, get the scope and target again and force one reset cycle with the following commands:

   scope = cw.scope()
   scope.default_setup()
   target = cw.target(scope)

   scope.io.nrst = "low"
   time.sleep(0.7)
   scope.io.nrst = "high_z"
  1. Run captures as usual

Is that globally ok?

Thanks again,
Quentin

I’ll have to look into this. It looks like OpenOCD support for this target is currently in development, and I’ve seen PyOCD recommended as well, so there might be a few different options.

Our JTAG implementation might not work with this target - it’s just a bitbanged emulation of an FTDI chip, so lots of things aren’t really right with regards to frequency or meeting the requirements for buffers/commands. You may need a third party JTAG programmer.

BTW, 0xACE3 is correct for the Pro.

Hello Alex,

Do you have any update on this?
Do you know if there is a documented way of programming this target board in the current project state, or if someone managed to do it recently?

Thank you,
Quentin

Sorry, haven’t had a chance to look at this yet, I’ll try to take a look this week.

Sorry about the delay on this. It seems like OpenOCD doesn’t support this by default, but there is a proposed patch that does: https://review.openocd.org/c/openocd/+/8189. I’m still playing around trying to get this to work with a tigard GitHub - tigard-tools/tigard: An FTDI FT2232H-based multi-protocol tool for hardware hacking. I’m currently able to communicate over SWD, but there’s some flash configuration that needs to be done, so I’m currently looking in to that.

PyOCD also seems promising, but I haven’t had any luck with that yet: https://pyocd.io/

Thanks Alex. I will try the solution with the OpenOCD patch as soon as I can. I will update this thread once I have.

BTW I wouldn’t expect the debugging implementation in ChipWhisperer to work for this. You’ll almost certainly need an external debugger.

Hello Alex,

I have just tried to program the target board using the OpenOCD patch. However, when running the ‘openocd -f lpc_configfile.cfg’, I get the following output and warning:

$ openocd -f lpc_config_file.cfg 
Open On-Chip Debugger 0.12.0+dev-00634-g23c33e1d3-dirty (2024-10-10-15:03)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : FTDI SWD mode enabled
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Warn : Haven't made progress in mpsse_flush() for 2002ms.
Warn : Haven't made progress in mpsse_flush() for 4004ms.
Warn : Haven't made progress in mpsse_flush() for 8004ms.
Warn : Haven't made progress in mpsse_flush() for 16002ms.
Warn : Haven't made progress in mpsse_flush() for 32005ms.
Warn : Haven't made progress in mpsse_flush() for 64009ms.

And so on…

Is it related to the remark you made in your last post about the (external) debugger? I did not understand what it meant actually…

Incidentally, do you know how we can stop this openocd command properly? Ctrl+C doesn’t work, neither does kill (without -9), and I am afraid to make things go wrong if I brutally disconnect the chip/force kill the command…

What was meant was that you’ll need a commercial programming tool such as Segger J-Link (which we have confirmed to work).

We’ve updated the RTFM page to reflect this.

What was meant was that you’ll need a commercial programming tool such as Segger J-Link (which we have confirmed to work).

Ok, thank you. It’s just that from Alex’s response, I more or less understood that using the OpenOCD patch he mentioned could be sufficient to have it work without a third party tool.