Nuvoton MS51 Programmer

Here’s a really rough start on an Nuvoton MS51 programmer.

Important notes:

  • This was never meant to be included in “official” build
  • I just spent a couple of hours refactoring for the big cleanup that was done to the code in the last few months or so. (BTW, I like the changes :slight_smile: )
  • This doesn’t work. I wasn’t sure if the chip was locked or if this is just junk. I’m only offering it publicly because another user was looking for something.

With that out of the way…

I started this last fall to play with a challenge badge I got at DefCon a few years ago. The badge had a Nuvoton MS51 mcu on it and I wanted to read out the flash.

I found an MIT-licensed project to start from at GitHub - steve-m/N76E003-playground: Software related to the cheap Nuvoton N76E003 8051-based MCU · GitHub along with some other docs and built a BP mode around that.

As I stated above, I didn’t get it to work with the chip, so I finally bought a cheap nuvoton programmer to see if I could talk to the chip with that. The idea was that I would try that, and if it worked, then I’d debug my code based on what a logic analayzer showed me. I never got around to that point. Sigh

What exists so far:
The mode and a command to try to read the chip config. The code will try to connect to the chip and look at the config.

Start by setting nuvo51 mode and enabling power suppy:

HiZ> m nuvo51


Mode: Nuvo51
N51PGM_init()

Nuvo51> W 3.3

3.30V requested, closest value: 3.30V
300.0mA requested, closest value: 300.0mA
Undervoltage limit: 2.96V (10%)

Power supply:  Enabled
Vreg output: 3.3V, Vref/Vout pin: 3.3V, Current: 7.5mA

Display shows pin assignments:
I00 - RST
I01 - CLK
I02 - DAT
I03 - TRG

The only command is config:

Nuvo51> config -h

usage:
  config [read|write|erase|verify] <file>

Do stuff with Nuvoton config

actions:
  read            Read Nuvoton config
  write           Write Nuvoton config
  erase           Erase Nuvoton config
  verify          Verify Nuvoton config

positional arguments:
  <file>          Output file path

options:
  -h, --help      Get additional help

examples:
  Read config: read cfg.dat
  Read config and save to file: read cfg.dat
  Write config from file: write cfg.dat
  Verify config contents with file data: verify cfg.dat
usage:
  config [read|write|erase|verify] <file>

At this point, it doesn’t really do any of those 4 actions - I only got as far as trying to get the chip into ISP mode. It spits out some debug for that:

Nuvo51> config read cfg.dat


Nuvoton 8051 ICP programmer - config handler.
Action: 0/read, filename = cfg.dat
N51ICP_enter_icp_mode(false)
N51ICP_bitsend (0x5aa503, 24 bits, 60 delay): 010110101010010100000011
N51ICP_read_device_id
N51ICP_send_command(0x0c, 0)
N51ICP_bitsend (0x000c, 24 bits, 20 delay): 000000000000000000001100
N51ICP_read_device_id
N51ICP_send_command(0x0c, 0)
N51ICP_bitsend (0x000c, 24 bits, 20 delay): 000000000000000000001100
get_device_id() result 0000
N51ICP_bitsend (0xf78f0, 24 bits, 60 delay): 000011110111100011110000

Nuvo51> 

So, it didn’t get into ISP mode and couldn’t read the chip ID. It will sit at the get_device_id() line until you hit the button.

At some point this fall, I’ll get back to it. First, trying the programmer I bought to verify that anything will talk to the chip. If so, I’ll go back and get the BP version working on what I find.

Unless anyone else happens to have a chip, the time, and desire to look at this. The updated code, rebased to upstream as of today, is at: GitHub - mbrugman67/BusPirate5-firmware at add_n51_newstyle · GitHub

Also - I’m seeing this error in the build:

In file included from /Users/runner/work/BusPirate5-firmware/BusPirate5-firmware/build/_deps/pico_sdk-src/src/common/pico_base_headers/include/pico/assert.h:18,
                 from /Users/runner/work/BusPirate5-firmware/BusPirate5-firmware/build/_deps/pico_sdk-src/src/common/pico_base_headers/include/pico/types.h:12,
                 from /Users/runner/work/BusPirate5-firmware/BusPirate5-firmware/build/_deps/pico_sdk-src/src/common/pico_base_headers/include/pico.h:26,
                 from /Users/runner/work/BusPirate5-firmware/BusPirate5-firmware/build/_deps/pico_sdk-src/src/common/pico_stdlib_headers/include/pico/stdlib.h:10,
                 from /Users/runner/work/BusPirate5-firmware/BusPirate5-firmware/src/commands/infrared/tvbgone.c:35:
/Users/runner/work/BusPirate5-firmware/BusPirate5-firmware/build/_deps/pico_sdk-src/src/common/pico_util/include/pico/util/fixed_bitset.h:70:1: error: static assertion failed: ""
   70 | static_assert(sizeof(__not_real_bitset32) == fixed_bitset_sizeof_for(1),"");
      | ^~~~~~~~~~~~~
/Users/runner/work/BusPirate5-firmware/BusPirate5-firmware/build/_deps/pico_sdk-src/src/common/pico_util/include/pico/util/fixed_bitset.h:71:1: error: static assertion failed: ""
   71 | static_assert(sizeof(__not_real_bitset33) == fixed_bitset_sizeof_for(37), "");
      | ^~~~~~~~~~~~~
make[2]: *** [src/CMakeFiles/bus_pirate5_rev10.dir/commands/infrared/tvbgone.c.o] Error 1
make[1]: *** [src/CMakeFiles/bus_pirate5_rev10.dir/all] Error 2
make: *** [all] Error 2

Not sure what that’s all about - so I just hacked it away (I pulled the asserts - yikes!). I just didn’t have the time to go look at it; must be a problem with the files on my local machine, but I think they get pulled from the upstream rPI PICO repo…

Don’t pull the asserts, it’s a real bug. I have a PR waiting for approval. It was CoPilot-evaluated, and I agree with the fix, so I told it to fix it (and CoPilot did so correctly). But, as is proper, I cannot approve my own PR…

The asserts are in SDK code, not in the BP project itself. To be honest, I just commented them because I didn’t have the time to really look.

If I blow away the build directory, cmake will re-download the Pico SDK and they’ll be back.

Can you link your PR? I’m curious where the actual problem is. (I suppose I can find it myself, but I’m being lazy here and you’ve already done the legwork :blush: )

Ah, I see it now. That’s an ugly hack in the tvbegone code. Did the PIC toolchain not have stdint.h? 90% of my 8-bit/small micro work was on Atmel; I didn’t have a lot of exposure to PIC.

The good thing is that once this PR is merged I can just force a repull of the SDK to restore the asserts.