"Arcflash" A3000/A3xx/A4xx/A5xx/A5000 in-system programmable ROM -- any interest?

[sP1d3r]

Probably https://www.tag-connect.com/

Thanks Ian, it looks like a fancy cable shroud to me!
Looks like a special tool is needed to make up a suitable cable, so I'd stick with with Molex connectors because myelin's 10-pin header pinout matches the little adapter board that plugs into a Platform USB downloader.

[IanJeffray]

Is TC 'temperature compensated'?

Probably https://www.tag-connect.com/

Yes, sorry. myelin uses the 6pin version on both ArcFlash and the POSTbox. I put the 10-pin "full fat JTAG" in my own designs, but skip the retention holes. It's a good system, but the TC cables are irritatingly expensive. I buy from Digi-Key. Note that there are lots of variants of the cables - pick the one that suits the programmer you have. I bought "TC2030-CTX" https://www.tag-connect.com/product/tc2 ... arm-cortex and then use an Olimex 10 to 20 adaptor to standard full-size IDC for use with J-Link, viz:

[IanJeffray]

I'd stick with with Molex connectors because myelin's 10-pin header pinout matches the little adapter board that plugs into a Platform USB downloader.

Actually I think he just said the pinout on this board is different to that on the POSTbox, which is the standard layout. I've not checked.

[myelin]

Yeah, the 0.1" header on Arcflash isn't a standard Cortex header, I'm afraid. (The one on the POST Box is.)

I've just pushed an update to the BOM to clarify that the four decoupling caps on the bottom layer are optional; you can get away with just populating the top layer:

https://github.com/google/myelin-acorn- ... erials.txt

Good luck!

[myelin]

Found some time today so I won’t be too far behind you testing v3! (Pictured before cleaning up all the solder bridges after reflow.)

[IanJeffray]

Found some time today so I won’t be too far behind you testing v3!

Oh you're way ahead. Excellent. I've not sorted out the plan for soldering the BGAs yet and DHL lost my stencil -- just arrived today and Xilinx programmer still en-route. I've now kitted to make up all 5 boards (was just planning on a couple originally) and plan to test on A3000, A300 and A400 boards initually.

What's the status of the RiscPC/A30x0 adaptor? I can't quite follow from the posts in this thread if the spacing issue was resolved one way or another - I'd be quite keen on trying in RiscPC, A30x0 and A4000.

[myelin]

Oh you're way ahead. Excellent. I've not sorted out the plan for soldering the BGAs yet and DHL lost my stencil -- just arrived today and Xilinx programmer still en-route. I've now kitted to make up all 5 boards (was just planning on a couple originally) and plan to test on A3000, A300 and A400 boards initually.

What's the status of the RiscPC/A30x0 adaptor? I can't quite follow from the posts in this thread if the spacing issue was resolved one way or another - I'd be quite keen on trying in RiscPC, A30x0 and A4000.

The stencil makes it all possible I use Chip-Quik leaded solder paste (available in the US... hopefully still in the UK?) and very carefully place everything with a pair of tweezers, using an OptiVisor DA-4 so I can actually see what's going on. Then it all goes on a little electric hot plate at some indeterminate temperature for a bit: I put it on the 300 degree setting and wait until the paste on the last component stops bubbling. Usually this is just when the board starts to smoke a tiny bit... at that point I turn off the power and pick it up with tweezers and set it on the raised corner of the hot plate to cool down for a few minutes. Finally I fire up the soldering iron and wick up all the solder bridges, of which there are usually many... the BGAs always seem to work out fine, but anything with 0.65mm or 0.5mm pins seems guaranteed to have at least one bridge. Make sure to check for bridges on the USB connector, as often they're hidden underneath a bit.

Then I do all the usual things: stick it on a lab PSU at 5V 0.2A to see if I missed any shorts, then plug in the J-Link, check voltages, program the bootloader, program the MCU firmware, program the CPLD (note that you don't need a Xilinx cable; in fact there's no JTAG port exposed on the board, so you have to program the CPLD via the MCU), then build and program a set of ROM images into it.

^ I've updated pretty much everything above tonight, so the build process should make a bit more sense now! Also figured out how to do a custom Arduino variant, so it'll identify on USB as "Arcflash" rather than "Circuit Playground Express"

I don't believe I ever fixed the spacing issue, although I did awkwardly solder four rows of bent header pins onto one board, which let me try it out on my RPC!

[sP1d3r]

The problem with components like the smd resistor networks and smd chips with 0.5mm pin spacing is that in industry these parts are placed by machine on solder paste that's printed onto the pcb pads, before the reflow oven.

Without a solder paste printer and a pick and place machine these parts are a lot more fiddly to use, it's possible to use them but it won't save any time.

[myelin]

The problem with components like the smd resistor networks and smd chips with 0.5mm pin spacing is that in industry these parts are placed by machine on solder paste that's printed onto the pcb pads, before the reflow oven.

Without a solder paste printer and a pick and place machine these parts are a lot more fiddly to use, it's possible to use them but it won't save any time.

I would say that using a stencil, placing four 8-way resistor packs, reflowing, then cleaning up with wick was still quicker than placing 32 separate resistors would have been... it definitely wasn't as convenient as I would have liked, but it doing them by hand would have been even less fun!

I fired up the first Arcflash v3 board in an A3000 today, and it worked as well as the v2 board that was in there already, so that was a success!

Unfortunately the machine itself seems to have gone backwards a little since the last time I worked on it -- it produced a weird pattern on screen when in the Arcflash bootloader, but managed to get into the self-test part of RISC OS 3 (purple then red, followed by black after a while). Not what I was hoping for (although this means my POST Box will get another workout as I debug what's wrong!), but promising for Arcflash, as it means the series resistors don't appear to have broken anything *yet*

[myelin]

Progress, progress... hooked a POST Box r2 to the bad A3000 with Arcflash v3, manually selected RISC OS 3.11 with "Y22" on the Arcflash serial port (Y = select bank; 2 = select bank @ 2MB; 2 = select bank size 2MB) and it output a nice self-test:

Code: Select all

SELFTEST R1.47
ROM :
M Size :
M Size 0200.08
Data :
Data @ 2000000
Data-F FFFFFFFF
Data-P FFFFFFFF
IOC :
IOC FBF8C280
IOEB :
SRAM :
SRAM Err 11
IOinit :
Speed :
Speed 1F40.1.2
RAM :
skipped
CAMs :
skipped
VIDC :
ARM ID :
skipped
FAIL : 00020102

Looks like no RAM! Scoping up the Oe2* and We2* lines on the RAM expansion header, it looks like Oe2* is sitting at ground. Pulling it high with a 1k resistor, it got all the way to 5V, so it looks like it's floating or very very weakly being pulled down. So I guess IC28 (74HC139) needs replacing.

Sticking the Arcflash v3 (serial #10) in another A3000, everything works just fine. I was pleased to see that running test_memc_memory.py against the attached POST Box showed that it can handle high_rom_time=3, i.e. the fastest ROM speed -- 2 clocks for random access, 1 clock for sequential, so the same speed as RAM. This means SYS "OS_UpdateMEMC",64,64 should still work

[myelin]

Tonight's project is to try to figure out why I'm getting serial port issues on my v3 board: serial reception just stops working halfway through a ROM upload sometimes, and the upload script times out, then if I connect to the Arcflash manually (screen /dev/tty.usbmodem* on my Mac), I see the connection banner but it doesn't seem to be receiving my keystrokes.

I seem to be able to reliably reproduce this by running python3 tools/test_serial_comms.py, which succeeds, then running python3 tools/make_arc_rom.py upload, which fails.

I don't remember getting this before, so I'm hoping maybe it's a regression in the Arduino libraries. 1.8.11 seems to be reliably bad, and my current build script doesn't work on versions before 1.8.1, so I'm trying that now. Slow going as testing to try to get the crash takes a good 10 minutes...

[IanJeffray]

One built. Dry fit. Looks good. Now to sort out programming the MCU (cart, horse...). Looks like right-angled pins for A18-A21 may be a good plan.

[IanJeffray]

With some additional guidance from Phil, and addition of the POR/reset line options, this is now working nicely in an A305. I think this is just amazing - really cool. Installation of the 6 wires to the board isn't difficult, but pushing the whole thing down in to the ROM sockets proved to be quite troublesome.

Pointless video of me switching between Arthur 0.30 / Arthur 1.20 / RISC OS 2.00 :
https://www.youtube.com/watch?v=nH9Ej_SJoaM

Now I need to upgrade the A305 to an A310 or move this ArcFlash board in to another Arc with more RAM so I can run RISC OS 3.1x and ultimately RISC OS 3.20

[sirbod]

Nice.

At some point I’ll modify the Module init sequence in 3.20 to “unplug” unnecessary Modules on machines without enough RAM for them. I’ve not actually tested to see what happens if it runs out of RAM during init, in theory it should show a visible Module init error and possibly drop to a Supervisor prompt where you can *UNPLUG

[IanJeffray]

At some point I’ll modify the Module init sequence in 3.20 to “unplug” unnecessary Modules on machines without enough RAM for them.

RISC OS 3 doesn't work at all on an A305 though - passes POST but then doesn't even get as far as "RISC OS" so I don't think the issue is module init or RAM usage per-se. It would be practically pointless but amusing to try and sort this out so it could work on an A305 -- it works fine in Arculator configured as an A305! This sort of hacking and testing is exactly what it's great to have ArcFlash for - when 'real hardware' behaves differently to emulators.

[sirbod]

RISC OS 3 doesn't work at all on an A305 though - passes POST but then doesn't even get as far as "RISC OS"

I seem to recall RO3 needing a minimum of 1MB RAM when I was working on RO3.20, I might be misremembering though.

You could quickly answer that by trying RO3.20. If you don't see a screen full of Modules being initialised, it's failed before the Module Init phase.

Prior to RO3.20, Modules were added to a list and then Initialised in one go. I rewrote that to Initialise Modules as it finds them and display the Modules name, primarily to handle the situation you describe where a failed Module can lock the boot process after POST.

[sirbod]

Has anyone looked into how we manufacture these once the testing is complete?

Very people people will have the equipment or skills to make these at home, so if they're going to be viable, we'll need a manufacture that can do the full assembly at a sensible cost for the low numbers involved.

Does anyone have experience or knowledge of suitable companies, that could source quotes and minimum orders?

[IanJeffray]

Has anyone looked into how we manufacture these once the testing is complete?

Very people people will have the equipment or skills to make these at home, so if they're going to be viable, we'll need a manufacture that can do the full assembly at a sensible cost for the low numbers involved.

Does anyone have experience or knowledge of suitable companies, that could source quotes and minimum orders?

Yes, and yes. Stay tuned

[steve3000]

Very people people will have the equipment or skills to make these at home, so if they're going to be viable, we'll need a manufacture that can do the full assembly at a sensible cost for the low numbers involved.

Some software changes will probably be needed for more general use though. For example at the moment Arcflash boots to the OS-selector in a 15khz screen mode on every start up. This is fine for testing on a multiscan monitor, and although it's easy to rebuild with the right tools (I've rebuilt mine to default boot to VGA), a more elegant solution will probably be needed for most users - eg. holding down a key on start up to jump into the OS-selector, otherwise system boots to the last used OS?

Also, a way of updating the flash from within RISC OS would be nice

[myelin]

It’s performance evaluation season at work right now so my plans are delayed a week or two, but the latest Arcflash board design is looking good and working for me and Ian, so I’m going to build a little batch from the components I have here (I think I have enough for 10 boards). If those all work for people, Ian is interested in organizing some more reliable production

Steve sent me some code and ideas for being able to update the flash from inside RISC OS, that I haven’t done anything with at all! I agree about the screen modes thing too.

[sirbod]

Good news, sounds like it’s all in hand.

[IanJeffray]

Phooey. A4000 fits the (incorrect) "RiscPC" PCB adaptor, but fouls a couple of large caps and the expansion sockets. (I think the RAM will be ok if it's tilted a bit). Definitely time for a design shuffle - ah well.

Anyone want one of these bare adaptor boards FOC? I accidentally ordered a bunch and they're no real use to me. Just PM me your address.

[myelin]

Hah, so is the incorrect RPC spacing actually correct for the A4000?

[IanJeffray]

Hah, so is the incorrect RPC spacing actually correct for the A4000?

Yes, it seems so. I've not pulled the ROMs yet as I want to fit longer pins on here first due to the clashing, but the pins snuggle the ROMs very nicely...

[EDIT: I've not actually checked the pinouts are even compatible yet!]

[IanJeffray]

[EDIT: I've not actually checked the pinouts are even compatible yet!]

Yep - it looks compatible, as I'd assumed. The OE's are used the other way around which shouldn't matter, and A19 is connected LA21, surprisingly (Though isn't bussed on the schematic, unusually).

I'll be building this up fully on Weds, all being well

A4000 top, RiscPC bottom...

[IanJeffray]

Umm.. ok, no. This is weird. It's like the width of the sockets is actually different, not just the inter-socket spacing. It's just a tiny bit off, but it just won't go. Dang.

[IanJeffray]

Big gorilla with nasty, nasty thin and crappy Chinesium header-extenders says "it fits now".

[myelin]

Hah! Nice work!

BTW you were asking about my soldering process -- I recorded a video of soldering up the first r3 POST Box a few days ago to show what's involved. That one doesn't have any BGA, so I'm going to try to record another one of soldering up a batch of 3 or 4 Arcflash v3 boards soon, but the process is the same. The only difference is that it seems to Just Work for the BGA chips; so far they've just always reflowed fine! Possibly because I spent days obsessing over the correct solder mask pattern for them and reading datasheets about reflowing them... maybe I just need to modify my QFP footprints and those will all reflow fine tooo

[IanJeffray]

BTW you were asking about my soldering process -- I recorded a video of soldering up the first r3 POST Box a few days ago to show what's involved.

I saw the video - really good! I was shocked how cavalier your paste strategy was (no fixing of the PCB, no levelling using other PCBs, repeated spreading not "one motion") and the blobby paste outcome is exactly what I've had in the past and just given up there. I'll likely stick to "peck" soldering as it only took me 30mins or so to put the non-BGA parts on ArcFlash anyway -- and seeing flooded legs always gives me huge itch. I was really boggled by the casual hotplate operation too - will definitely give this a shot. Do you paste just the same when doing BGAs?

One of the most impressive things for me about your video though was your recall of what all the parts were actually doing, both in circuit and in terms of their connection to the target. I think it's quite rare for people to explain their circuits, and particularly reasons for part choices.

[myelin]

Thank you!

This sort of stuff is why I wanted to record some of this. The process of home reflow often looks like it's going awfully, and the whole thing is going to fail, but then still comes out with pretty good results, at least for the BGAs!

And on that note, I soldered up four Arcflash v3 boards last night, and made another video

--> Arcflash v3 assembly process (reflow, fixup) on YouTube <--

It took an hour and a half all up for the four boards, and I managed to get the overhead camera a bit closer to the table, so you can actually see what's going on most of the time. The BGA placement happens around 25 mins in, and you can actually see the components reflowing quite well.

(Sidenote: I thought the reflow process had killed my webcam, but rewatching it, I see the glitches start before I even turn the hotplate on, so maybe there was already something wrong with it? Will see if I can RMA it.)

I mention this a few times in the video, but I wonder if modifying the landing pattern for the non-BGA chips is what I need to do. The BGAs are admittedly wider pitch (0.8mm is the smallest), but they *never* start out with smeared solder paste, just perfect little grey hills, and my footprints generally are geared towards hand soldering. I'm curious to try making the pads I use for all the other components a bit smaller at least, even if I don't reduce them to the point that they're impossible to hand solder...

Bonus behind the scenes shot of what it took to record all this: