Thanks for the PR. It will likely take a while to merge this because the new applet doesn't quite follow the conventions in the other applets, and I'd like all of the in-tree applets to be written in the same style.

Thanks for the comments - I worked through them, and hope the changes are appropriate.

Waiting to get hold of a cc2430 to check bank switching.

Hurrah - works on with the newer banked Zigbee/BLE parts 253x and 254x

FInally got a CC2430 module and tested ok.

Just some comments/observations since I've been using this with a CC2530.

Programming with fast clock

Initially wasn't able to run the programmer very fast, trying anything over 200kHz seemed to not find the IC. Confirmed connections to PCB etc. TI datasheet states that 12MHz clock is supported.
Hooked in my scope, and you can clearly see what the issue was.

The CC parts send 2 pulses while reset is inactive to enter debug mode. My circuit has an RC with a 100nF capacitor on the reset pin, so the short 5us wait between activating and sending pulses didn't provide enough time to fully pull RESET LOW.
I added a small delay between RESET_ON/RESET_OFF, fixing this issue.

Programming a sleeping part

If my CC2530 target is in deep sleep mode, it's internal 1.8V regulator is off, and it's running on the Sleep Timer clocked by an external 32kHz crystal. I'm not able to program the device on the first try. If I run the tool again while the chip is active in it's startup code, then it's found and programming works.

Not sure if there needs to be a slightly longer wait, potentially for the 1.8V regulator to start up? TI's docs don't mention anything special about entering debug mode while the target is asleep.

I tried an extra initial 1ms Reset pulse, 1ms wait, before standard entry procedure, this works sometimes
My modules have a EMI shield on them, so I've not probed the 1.8V regulator cap, that's probably the next thing I'll take a look at.

~ Edit: ~
I've been looking at it, I think my reset cap is still causing issues. Adding an extra delay after RESET_OFF seems to work a lot better. I suspect even with the flush, sometimes the glasgow was ready with the ID commands as the reset line was still being released, causing the command to be lost.

# Generate entry signal - two clocks while reset held
await self._send(Operation.RESET_ON, [], 0)
await self._delay_ms(1)
await self._send(Operation.DEBUG_ENTRY, [], 0)
await self._delay_us(100)
await self._send(Operation.RESET_OFF, [], 0)
await self._delay_us(100)
await self.lower.flush()

Thanks - yeah, looks like resets need a bit more TLC. I’ll dig out the other devices I have and explore.