The wiring between the various boards in the "nuclear football" form-factor MEGA65 is being a pain in the backside for me. So it's time to separate each layer of the construction, so that it just has some convenient connectors that can be accessed from the edge and connect into the neighbouring layers. And ideally, so that nothing can be plugged into the wrong place --- so every connector should be different.
Let's start from the MEGA65 mainboard layer, which has the most connections to elsewhere.
The cable to the MEGA65 keyboard we can ignore as fairly trivial and solved.
Then we have some intra-board wiring between the MEGA65 PMOD ports and the low-power energy-management FPGA module. After that, there's the connections from both of those to the cellular modem layer, and also to the top-layer where there are a couple of momentary action switches that connect to the MEGA65's reset pin on the expansion port (but it might get moved to a PMOD), and to the wake pin on the low-power FPGA module.
So let's map out those links, and decide which connectors we'll use for each.
Bugger -- I just remembered we have to break out two pins from the keyboard connector. So I should just design a PCB for that. Maybe I should also design a PCB for the PMOD connector, that implicitly rotates the connections we need 90 degrees, so that it's easier to fit. I can then also mark each pin on these with the colour/function of the wire, to make it easier to assemble.
Pins 6 and 7 on the keyboard connector are what we need. The extra connector will have to be on the underside of the PCB, so that it doesn't sit too high, because of the limited vertical space available to us.
Okay, so I have a simple design for this now:
The idea is simple: Turn the keyboard connector 90 degrees which saves vertical space, and make route out the pins we need for the UART to either the keyboard or to the UART pin header.
So that's that one. Now to make the PMOD adapter. Here we'll do a 90 degree turn as well, to make life easy. And we'll also make two output connectors on it --- one with GND and one of the UART lines to the cellular modem, and the other with GND and the other UART line that goes to the low-power FPGA board (this is because the low-power FPGA sniffs the cellular modem's UART to detect RING and other important messages, so that it can wake the MEGA65.
Actually, to make life easier, we'll add a relay pin for the UART line that goes to the main FPGA, so that there's just one connector from one place that goes to the cellular modem from this deck, since we already need two pins going from the PMOD board to the low-power FPGA board, it's no real imposition to have a 3rd wire.
This means that we'll have two three-pin connectors from this PMOD adaptor board.
I'll also add jumper headers to allow switching the UART pin polarity, because I'll otherwise be sure to have it the wrong around.
The layout of this one is fairly simple, with placement of the connectors carefully made to avoid hitting the 2nd PMOD or any other tricky bits.
Okay, PCBs ordered, along with the connectors I don't have laying about in stock.
It's now quite a lot later, and I'm trying to pick up where I left off, including with updated MDF cut panels to fix various problems.
And of course the diode I soldered onto the IceSugar Nano has fallen off, and the photo I made in another blog post is too blurry to be really useful. I did at least describe what I was doing, but I should make sure I document it properly here, so that anyone needing to do it themselves, or fixing a fallen-off resistor, can do it. This is the circuit that gets modified:
The change is to replace U3 with a Schottky diode that goes from pin 2 to 3, like this:
And here's what it looks like assembled:
So let's now work out the rest of the loom, and make a nice big friendly diagram, because if nothing else, I've completely lost track of which wires go where.
We'll start with the IceSugar Nano, since that's what I've got in front of me. It handles UART pass through from the cellular modem to the main FPGA, as well as powering on and off different sub-systems. The source code for the firmware is here, and within that, we can find the pin allocation in the top level VHDL file:
entity megaphonepwr is
port (
CLK : in std_logic;
-- USB UART interface
USB_TX : out std_logic; -- B3
USB_RX : in std_logic; -- A3
-- Cellular modem UART interface
E3 : in std_logic;
-- Pass-through of cellular modem UART interface
E1 : out std_logic;
-- I2C interface for IO expanders
B1 : inout std_logic := 'Z'; -- SDA
A1 : out std_logic; -- SCL
-- Power button to force-wake the main FPGA power
B4 : in std_logic; -- Power button wake pin
-- Power control pins for six subsystems
LED : out std_logic := '1'; -- Also B6, used to control main FPGA power
C6 : out std_logic := '0'; -- Sub-system C6 power enable
C5 : out std_logic := '0'; -- Sub-system C5 power enable
E2 : out std_logic := '0'; -- Sub-system E2 power enable
B5 : out std_logic := '0'; -- Sub-system B5 power enable
C2 : out std_logic := '0' -- Sub-system C2 power enable
);
end entity;
And with the handy summary of the pin assignments on the module itself:
Note that some pins appear in two places on the connectors! e.g., A1 and B1. That just gives us more choice as to where we plug leads.
So, E3 is the UART TX from the cellular modem, and E1 is the UART TX relayed by the module to the MEGA65 mainboard. The cellular modem gets mapped to MEGA65 Buffered UART #0, which is the one on the PMOD connector (and the same one that the MEGA65 Expansion Board Integrated JTAG / WiFi appears, which creates some commonality).
B4 is the soft power-button that can wake the whole system.
B6 is the output line that controls the power to the MEGA65 mainboard and LCD display.
What I can't yet see is the UART RX that accepts UART data from the MEGA65 mainboard, which is also shadowed by the USB UART interface. That's A3, which wasn't marked in that VHDL file (I've added it to the block above, in case you thought I was failing to see it there.) This gets mapped to Buffered UART #1, which is the one on the MEGA65 keyboard connector. So A3 and B3 need to get routed there. Okay, added those.
Now, GND and 3.3V need to be connected to the low-current power supply that's always one, so that the power management module can be doing it's thing.
The rest of the pins are reserved for controlling power to other subsystems or I2C devices, of which we currently have none.
So I think that's everything that this module needs to talk to. Here's my little diagram of that part of things:
So let's look at what needs to connect to pins on the MEGA65 mainboard, and the expansion port breakout. In particular, the links to the module above, but also to the reset button on the top deck, joysticks and screen.
And there I see that Past Me disagrees with Current Me about the PMOD pinouts. The adaptor for the PMODs has cellular _and_ power management UART pins broken out. But the default development builds don't yet have it -- just the 932-megaphone-second-uart branch(es).
What I need now is to find the KiCad project for the little PMOD board, to check the pin assignments on that. It's in https://github.com/gardners/mega65-rugged-case/tree/main/pmod-adaptor. And it looks like I did something fairly sensible, despite how I've changed things since to use the keyboard adaptor:
Sure as eggs I'll have the UART RX/TX wrong way around, but that's just two wire plugs to switch. But we have it captured in the diagram, that's the important bit:
Right. So that's those. I've also added the reset and power-on buttons. I suppose I should add joysticks and VGA for completeness. Done.
So now it's probably time to add in the high-current switched DC supply for the mainboard and LCD panel etc, and then the low-current 3.3V supply that runs the power management FPGA.
Now let's add the cellular modem board, and the independent power system for it. Well, actually, no. For now, we're going to keep things simple: Cellular is always on. That lets us use an off-the-shelf 5V to 3.3V step down to take the always-on 5V we need to feed the cellular modem, and can power the IceSugar with that. Later when we start integrating this all onto a single board we can add in the low-current and high-current DC:DC modules.
The MEGA65 can be turned off, though, which means we have to worry about back-current through the UART lines. 10K resistor in the lines from the MEGA65's UARTs to the other devices should basically look after that, especially if we make the IceSugar tristate it's UART relay to the MEGA65. The MEGA65 -> cellular path still has a potential leakage, but at 10K and 3.3V, we're talking fairly tiny current. I'm inclined to give it a try. If it's still problematic, then we can relay the UART from MEGA65 to cellular via the IceSugar, so that we can fully tri-state the backflow path into the MEGA65. Or maybe diodes in the UART lines would work. 3V is probably ample to read as logic high...
It goes without saying that we should not use the 3.3V rail from the MEGA65 to power anything else in the system, since that rail will only be available when the MEGA65 board is powered on.
But back to the UART isolation.
Actually, a better idea is to put a 74HC244 or 54HC244 in the path of the UART lines. The 244 has two 4-bit buffers with /OE signals that let us tri-state them. That way we can tristate output to any power domain that's off. The only nuisance is that the /OE's are active low, while our switchable DC:DC regulators are active high. I could add in an inverter, and probably once we have more power domains, that will make sense. But for now, we can just use a couple of the currently unused power control GPIOs in our existing IceSugar design. I'll just modify the firmware so that when we turn off the MEGA65 power, we turn on the MEGA65 UART isolate signal to the 244, and similarly for the Quectel cellular module. Then all we need is a decoupling cap on the 244, and a couple of 100K pull-ups on the /OE lines, so that everything stays isolated when the IceSugar first turns on, or is reconfiguring for any reason.
Okay. I think that all makes sense now. Off to Jaycar for the morning shopping for parts (the 244, some 100K resistors, the 5->3.3V DC:DC regulator and maybe a socket for the 244, if I can't find any 20 pin DIP sockets in my stash. I do need to tidy my stash up, so that I can find these things more easily in future.
Parts acquired. So let's start updating the diagram to pull it all together. Speaking of which, I had an idea just _after_ I got home from jaycar, which is that I could put a length of strip-soldered prototyping board down the side of the stack of boards, so that there's no (well, except for the high-current battery leads) mass of inter-board routing. I think it's a good idea in principle, but I'm not going to bother today. Partly because I'd have to re-laser-cut all the layers to make space. But also because I fully intend after this prototype to really aggressively start on the integration. All the power stuff on one PCB, for example, with just a pair of big fat terminals for the battery on one end, and the various switched rails coming out on other connectors. And the DC/solar battery charge stuff, too, once we get that sorted out.
So, enough procrastinating, and on to updating the diagram. I've added the power supply chains. So now let's draw up that 74HC244 diagram. Here's the pinout:
So we want VCC to the Ice's 3.3V, and 1/OE and 2/OE connected to spare GPIOs on the Ice, let's use B5 and C2. Then we can feed the UART relay through one, so that will be Ice E1 -> 1A1, and 1Y1 goes to the PMOD adaptor board. And the rest of the UARTs.
Here's how all that looks now. It is a bit of a jumbled mess, but it has everything we need, I think. It is really tempting to design up a quick little PCB that connects to the Ice sugar and hosts the buffer. But I want to avoid such rabbit holes right now, because my goal is to get the thing powering up and communicating by the end of the day, and powering itself on to receive a phone call by the end of the week.
What I don't have there yet, though, is GND bonds between the ICE and the MEGA65 and the ICE and the cellular modem. I should add those in. That's easy from the MEGA65 -- the PMOD board has a GND pin exposed. And there's a spare GND pin on the Ice board. But only one. There's not another spare for one for the cellular board. But we can live with that, because as shown above, for now we are deriving the Ice's 3.3V rail from the 5V rail that feeds the cellular board. So they already have a common ground plane.
Okay. So I think that's officially everything I need. There's still a few hours before Jaycar closes, but I don't want to cut it fine for anything I've forgotten. The main thing now is DC barrel connectors to make the various power leads. The previous 10A ones I made are just too stiff, and a pain to work with, so I'm going to make new ones with 5A wire.
That reminds me: I _had_ planned to put connectors in the middle of various runs in the loom, so that it's easier to assemble in the end. I may or may not still do that. It would be nice, for sure, but I think the bulk of the loom is intra-layer, with just the cellular UART and power having to go down the stack. So I think I'll wait until I really get annoyed before I resort to that. I don't know how long to make half of the leads yet, but we can deal with that later. What I will do, though, is solder on some header strip to the socket for the 74HC244, so that it's easy to just plug that in with female-female jumper leads. That will be much faster to prep than soldering tails onto every pin. That's probably the next thing to do right now. Right-angle, so that it isn't too tall to sit in the layer.
Look at me using the right tool to do the job quickly, easily, and without getting frustrated:
So now let's look at those DC barrel leads. We need 3: One for the MEGA65, one for the display (those two both feed off the same power supply output, but the screen one needs to be quite a lot longer lead), and one for the cellular modem.
I need to double-check if they're 2.1 or 2.5mm barrels, and got the power cables for the MEGA65 board and screen sorted fairly easily -- assuming they work ;)
That should do it. I can probably even test that it works, but first, I have to twiddle the pots to get 5V and 3.3V, before I plug the IceSugar Nano into it. Once I've confirmed the power supplies work, I can get to assembling the rest of the loom. Which I won't deny I'm not looking forward to the absolute rat's nest that it will be. Somewhat ironically adding the 74HC244 will simplify things, though, despite the nest of wires between it and the IceSugar. In particular, the UART lines to the cellular modem will both come from the buffer, instead of one from the MEGA65 and the other from the IceSugar.
... and I think I let the magic smoke out of the regulator with the segmented LEDs by reverse-polaritying it on the battery. I even checked it with the multi-meter first, although the reading was opposite to what I thought I'd seen yesterday. But I trusted Current Me, which I should have trusted Yesterday Me. Not sure what I messed up.
Anyway, that means I basically have to wait until tomorrow when Jaycar open again, as of course this happened literally 2 minutes after their closing time today. Such is life.
But, you know, I'm not too annoyed. I still got quite a lot done today. And there's a Jaycar around the corner from work, so I'll have the part before I get home tomorrow.
So I guess I'll knock off a few other tasks in the meantime.
The first of which was to finally give in and buy crimper and parts from Amazon. I don't like buying via them, but I do need the 2-day delivery this time around. So Tuesday I should have more crimpy parts than I can poke a stick at, and be well placed to fairly quickly assemble the wiring loom, and then discover all the things I got wrong :)
Okay, the crimper has arrived. Let's practice making a lead, so that I can slap down the neuron that keeps complaining about that.
There we go. I'm sure I'll get better and faster over time, but I made it, and it's connected.
So let's work on the first part: the IceSugar Nano and the buffer IC, since they have quite a dense net between them. I'll use headers that are the full length of the various connectors, so that we don't have to wonder where various single pins go. So let's look at that part of the diagram, and start doing this.
First, I hate crimping these leads almost as much as I hate having to cut pre-made ones and lengthen them by soldering a bit in the middle. But only almost.
Second, I had pin E5 listed in that diagram, which doesn't exist. I think it should be E3.
Third, I think I have the power management UART pins through the buffer wrong. Pins that can feed current into the MEGA65 get switched through the buffer. The buffers go from A->Y. So UART TX from the MEGA65 should go into an A, and come out a Y and into the IceSugar pin A3 (USB UART RX). And UART RX to the MEGA65 should go int an A from the IceSugar pin B3 (USB UART TX) and out a Y.
I've updated the diagram accordingly. Fortunately I spotted all this before I plugged those wires in.
I'm making better progress now, although I still don't enjoy the crimping process, including getting them to actually lock into the little headers properly. We'll use that as motivation to make the actual integrated version of all these little modules sooner rather than later. This is what it looks like now, with all the leads between the IceSugar Nano and the buffer IC connected:
The next round of connections I don't yet know the lengths I need for the leads, so I'm going to attach the IceSugar Nano back onto the MDF board, and then I can start gauging how long those needs to be, and make those parts of the loom. Key connections are:
1. UARTs to the MEGA65 (via the PMOD board and via the keyboard connector break-out.
2. Cellular modem UART.
3. Power control lines to the 9V supply for the MEGA65 and LCD panel.
I'll start with (1), not just because it's the lowest number, but because those lines are all on the same panel as the IceSugar Nano.
Oh, yeah, and I need to add a relay lead for the Schottky diode for the IceSugar, since I've got a header on the plug where it was connecting. Done.
Okay, so now back to the connections from the MEGA65 to the rest of the loom. The cellular modem UART's TX line already goes via the buffer into the IceSugar and from there gets relayed back out for delivery to the MEGA65 mainboard.
The Cellular UART's RX line, though, is currently direct from the MEGA65. We should probably make that go via the buffer, too, just to be sure. And it also makes the loom a bit simpler, in that nothing from the MEGA65 connects to a different level (well, except the reset button, but that we can live with. (There's a little fix I need to for for that, too, so that the connection for that can sit horizontally, instead of vertically which I'll tackle soon, too.)
But back to the Cellular UART RX line, the direction is MEGA65 -> Cellular UART, so we want to make the buffer gated on the line that we'll switch with the Cellular modem's power: If the Cellular modem is off, then there's no connection. Protection in the other direction comes for free from the buffer IC. So let's use 2A2 for the MEGA65 side, and 2Y2 for the Cellular modem side.
Diagram updated, and 5-pin header for the Cellular modem wired. I've only connected the UART RX and TX lines, not GND, since we should get common ground to the cellular modem via the derived 3.3V GND that feeds the IceSugar Nano from the 5V that feeds the cellular modem.
Next step is to replace the vertical 5-pin header on the cellular modem board with a right-angle one, so that it fits better on the deck. Once that's done, I think we're actually in a position where we can try powering up the IceSugar again, and see whether I've got all this plumbing in the wiring loom right.
Nothing too much to see here, but it's done: A nice angle connector.
Ideally I'll make it so that this also goes through the isolator switch, which shouldn't be a problem. The only complication is the lead path that gets a bit funny with the separated leads. But totally doable. I'll just make the leads a bit longer. Or possibly I'll relay the positive terminal on the battery to be closer to the isolator switch. One or the other.
I'm also thinking again about putting in a 2P battery arrangement, to give ~65Wh instead of ~32Wh, which would be nice. I need to use a right-angle barrel connector for the cellular modem to make it fit, though. And I should charge both the cells now, so that they end up on the same voltage when I connect them in parallel.
So let's plan the circuit for the battery:
1. Connect the two batteries in parallel.
2. Feed GND through the big fat isolation switch.
3. Wire in parallel the charger tail, the 9V switchable regulator and the 5V always-on regulator.
Probably the best solution here would be to use some terminal blocks, so that they can be connected, without risking leaving, e.g., ring connectors with exposed conductive edges.
I need four terminals for the batteries, then two more for the outputs, and a bunch of loops on the back-side to hook it all up. Should be easily do able.
Well, if I had wire that was about the right thickness for the HM3200 terminal block from Jaycar. Or I had less cheap terminal blocks with flat pushers that make it easier to put two wires in. Neither was of course true. The 25A cable I'd bought fit alone, but two of them was too fat. Even thinning it down it was basically impossible. In the end I canabalised some 15A 240V AC cable, and resorted to soldering the linked pairs to make sure the terminal block grabs it. Yes, soldered joints sitting in screw terminal blocks is not ideal, but this isn't really an industrial grade situation, so it should be more than fine.
So here's my soldered chain of cables to connect the terminals on one side of the block:
And then cut in half so that it fits easier, and the two 10A LiFePO4 cells fitted. It's a bit tight, but I think it'll fit. Having two cells gets us about 65Wh, comparable with a typical laptop, so we should be able to get several hours of active use with the screen on. At some point it would be a good idea to find a lower power LCD panel than the one I'm using right now. But it'll do.
See also the black fuse blocks on the cells. Good thing I put those in, because I seem to be having a good run of short-circuiting batteries. This time I absentmindedly connected the red cable for the positive of the 2nd cell to the negative terminal of the first cell... that was of course already connected to the positive terminal of the same battery. The 10A fuse did its job, though. So great to know that the slow-blow fuses (I want it to tolerate brief inrush-current situations) that they still blow basically instantly by higher current.
Anyway, we're progressing here, so I'll keep reworking the other power systems to pull from the terminal blocks. The cellular/IceSugar power feed is on the same board, so I can connect that now. Then probably the Deans-style charge connector to allow recharging using my external charger. It'll take 10 hours or more to charge with the default profile, but I can live with that.
Hopefully I can work out a good position for the two terminal blocks, then I can mark screw holes to add to the laser-cut pattern.
I've also put some MDF tabs just to stop the batteries flopping around while I work on it. I'll tape those down as well. When I assemble it, I might include some foam padding or something, so that they're better held in place once it's all assembled and starts getting carried by the handle, which means it'll be on it's side -- sensibly with the batteries at the bottom.
Anyway, apart from fixing the SVG files, the only thing remaining for this deck is to make an extension lead for the UART header, so that the various leads from this deck can all be passed up to the next level, thus avoiding the annoying wiring loom problem I had the last time. So excluding that, here it all is:
The Deans-style connector (sitting just under the black and green wires) is the charger input. The white connector somewhat to the right of that is a high-current connector so that the MEGA65/screen power supply on the next deck up can be fed, without having to be permanently wired down to this deck. Then right of the whole thing we have our wonderful huge isolation switch. That does get screwed onto the bottom of the next deck up, but that's quite manageable. Then of course on the left we have our telephone handset. And the black and green lead is the 3.3V power for the IceSugar Nano.
Oh yeah, and those who point out that that much wiring around that cellular antenna is far from optimal -- I agree entirely. But that's only the diversity antenna, and this is only a prototype, so we can live with it.
Anyway, it's almost 9am here, and the Adelaide Maker Space opens at 10AM and is usually fairly dead for the first hour. So if I get myself organised I can update those SVG files, buy some MDF sheets on the way, and get there for opening, cut the new version of this deck, and also cut a new set of pieces for the screen bezel etc that broke, and pedal back before lunch time, and get the whole thing assembled fairly quickly from here. This bottom deck and all the power distribution really is the camel's back, spare hump and a couple of legs of the problem.
Okay, so into Inkscape and update that SVG file. It only needs 4 holes added, so shouldn't take long. Our reference point at the top right edge of that section of the board is (384.351,77.919).
Really not much to see. But that's fine.
Okay, so SVG is updated, so time to go to Bunnings, grab some MDF, remember to actually take the laptop and a USB stick with me, and then do some stinky laser cutting :) I don't know if I've taken images of me in the Adelaide Maker Space. Like a lot of community maker spaces, they're really nicely setup.
Right, shoes on, and I'm off!
And I'm back.
In the process I found the SVG for the keyboard layer still has the weird problem where some of the letters and morse code symbols don't appear in the laser cutter software, despite appearing in Inkscape fine. After some ChatGPT help and then hand-editing the files and deleting some duplicate entities, I think that should be fine. I doubt I'll get back into the city today before the maker space closes. Or at least I shouldn't, if I want to get the rest of this milestone done today. It'll be easy enough to switch that plate out later, even if it just bugs me right now.
So let's check that the cellular plate has those terminal block holes cut in the right places. Three of the four are. The fourth is because I wrote 23 instead of 32 on the board after measuring that hole position earlier. That's fixed now.
Now we can make the cellular UART relay header cable, at which point everything we need on this deck is done, and we can start assembling the next layer onto it.
This is the deck with the absolute Kabelsalat / rat's nest. But it's mostly the loom between the IceSugar Nano and the buffer IC:
We're getting close to the point where we can start testing that buffer. But first, let's get the floppy deck on, the JTAG USB cable, and route it all so that it can sit in the bottom of the tough-case. It's taken long than I wanted to assemble, but I'm making steady progress, and hopefully the remainder will go quickly -- unless/until I find some horrible problems with the wiring, most likely with the UART plumbing.
I can see the IceSugar Nano, but it doesn't seem to be running the firmware. At least not every time it turns on. In some states it's triggering the power on to the MEGA65, and the MEGA65 seems to boot, but I don't yet have an LCD display hooked up that I'm confident works, so I can't be sure whether it's actually doing anything useful. I've plugged in a TE0790, so that I can talk to the JTAG and serial monitor, but also no luck actually doing that yet, despite the fact that the USB devices appear. So in short, the usual annoying early bring-up kind of problems.
I guess I should start IceSugar firmware and figure out what's going on there.
Okay, so the Schottky diode connection broke. I found a better way using a test point on the underside of the board.
And once it's powered the MEGA65 on, I see lots of power on events reported by the IceSugar as well. So I need to investigate that, too.
Okay, so fixed a few things here:
1. The power button needs a pullup. Enabled that in the FPGA.
2. The logic to detect power button events was pretty crappy. Various problems fixed with that.
Now pressing the BOOT button briefly causes the MEGA65 to power on, and holding it >2sec causes it to power off. You then can't turn it back on for 1/12th of a second of the button being released to provide robust de-bounce.
So that all works now, which is great.
I did connect an LCD panel and driver board here, and I'm not seeing a picture from the MEGA65 on it. So I'll have to debug if the MEGA65 is actually powering up properly or not. It could be that the MEGA65 is stuck on the dim purple display it does if the CPU is sad.
And I can't tell right now, because I can't talk to the USB serial adaptor on the MEGA65 right now -- which could be because of this problem. Or it could just be that my laptop is messing with the USB device or something.
Nope, it's not the USB TTY getting munched. And I can JTAG bitstreams over, so it's not that, either.
Hmm.. It could plausibly be that the machine's being held in reset by the reset button?
No.
Well, yes.
But not by _my_ button.
This MEGA65 has a broken reset button on the mainboard that was causing the problem.
So now I have a picture!
But it's quite dim, because I think the backlight driver for the screen isn't pushing enough power. Possibly because I'm feeding it 9V instead of 12V...
I just tried with the MEGA65 mains power supply (which is 12V), and maybe its... less dim. I think this panel is just a bit crap. I have two others of the type I can try, so maybe I'll give them a go. But for proof-of-concept a dim screen is totally fine.
What is good, is that the picture is crisp and clear in its dimness. But, yeah, my 9V power hack does leave it dimmer than it should be. I don't know if there's a jumper or something on the panel driver board to increase backlight current or something. Not that I can see.
Anyway, I've been at this for 13 hours today, so dinner and sleep time now.
While I'm annoyed I didn't get further, I do now have a MEGA65 that can sit in a box, and can be powered on and off using a soft power button controlled via an FPGA :) That's _way_ further than I was this morning.
Next weekend is here, and I've flashed the latest MEGA65 development core, which _should_ have the two UART things plumbed. But megacom doesn't see any traffic. So the next simple step is to check the UART pins for traffic, or put a loop-back jumper on them, to see if they're working in the core. If so, then it's tracing through the wiring loom to figure out what's gone wrong. The 74HC244 buffer is of course a likely culprit nexus for any problems I've introduced recently.
And now it's Sunday morning, and I've had a much better night's sleep (despite us switching over to summer time) and dealt with a various other external bits and pieces and can finally put my full attention on this.
First step is to see if we're generating UART traffic from the MEGA65 with the core I'm using. We'll look first on the PMOD UART, since I can get to that easiest. Once we're confident that the UART's doing the right thing, then we can check the 74HC244 is behaving sensibly.
And I can't see any traffic on the PMOD UART when I key mash into megacom. But I'm being thwarted from further investigation because it seems as soon as I start typing on the keyboard the power control FPGA decides to turn off the power to the MEGA65 main board. Which needless to say, it shouldn't. The battery's are still full, so that's not the problem. I'm guessing that it's seeing fluff on the power management UART line to it, which sometimes looks like the power-off command. It could be the boot button doing it, too, but that has to get held down for 2+ seconds to cut power, so I'm not really convinced that that could be the cause.
Also sometimes it just does it straight after turning power on with the boot button, which rules out the 2sec required. So either there's a bug in the firmware there, or it thinks it's being asked to turn it off. So, diversion in the form of plugging in the USB UART interface to it, and have words with it.
Maybe I should have it log power-off events as well and the reasons for them. Then I'll know straight away. Also it can let software know the reason for the last power-off, should that be useful.
Okay, working on that, and also implementing the logic to automatically set the /OE lines on the 74HC244 buffer when turning the MEGA65 on or off, and improving powerctl so that it can have a watch mode that lets us watch for events in real-time. That should let me figure out everything that's going on here -- unless of course plugging it into USB power prevents the problem ;)
Yup. Doesn't happen with USB plugged in. Remove it, and it turns off the MEGA65 straight away. And now plugging the USB back in, it's not enumerating, so I can't query it. I'm wondering if my diode for feeding 3.3V to the 5V line on the IceSugar isn't loose or something. It's odd that it now doesn't enumerate at all.
Great.
The FPGA isn't dead, so the 3.3V feed must be working. Now the machine isn't turning off, but the ICeSugar's still refusing to enumerate on USB. Well, I'll continue as best I can for the moment.
Okay, well, it looks like the development branch didn't have the 932-branch UART plumbing installed, so that explains that.
Now following discord, it looks like the UART pin assignments might be backwards on the builds that have it. But that I can live with, because I can just rotate the 3-pin connector.
Anyway, I'll grab a core for the 932-megaphone-uarts-only branch and try that.
Oh, physically power-cycling the MEGAphone got the USB enumerating working again. That's a relief. Sort of.
In any case, I've got the new core flashing now, and then we'll see.
Yay! The UART is visible on the PMOD. With the loom plugged back in, I don't see anything on there or on the keyboard UART, though. Let's see if I just have the PMOD UART connector backwards. Nope. No change. So time to look at that 74HC244 buffer.
The IceSugar outputs a constant 1Hz status update, so we should see constant traffic on the right pin. And of course I can check VCC and GND on the buffer, and then the /OE lines.
Okay, MEGA65 mainboard off, IceSugar powered. Let's see what we have at the buffer:
VCC / GND shows 3.3V. Both /OE lines are low. So far, so good.
I can see the power management UART TX from the IceSugar sending it's regular status reports on pin6 = 1A3, but I don't see them on pin 14 1Y3 yet. No, actually, I can't see it on pin6. So maybe my crimped loom is faulty?
I wouldn't be surprised. I'm not yet convinced that both my technique and the quality/precision of the crimp connectors is good enough to be sure. The nuisance is getting to the exposed pin on the IceSugar while it's assembled is non-trivial. But I guess I hvae to arrange it one way or another.
Now I'm confused: Over USB I can see the status messages, but not from right on the B3 pin -- or rather on the little hatch in the header for that pin. So either it's not really the USB TX pin, or that crimp isn't making connection to the pin below it.
Okay, so the UART TX and RX pins are backwards on the IceSugar compared with what I expected. That does explain things. And I should be able to just pop those two pins out and switch them around.
Yeah, USB_TX is TX _from_ USB to IceSugar, not from IceSugar to USB. Okay, let's switch those pins around... and still nothing.
Nope. I think I had them around the right way, because USB_TX shows bulk traffic when I run powerctl, consistent with it receiving the human-readable system status messages from the IceSugar. But I can't see the commands being sent on USB_RX which should be pin A3. Unless the pin labeled A3 isn't really A3.
Actually I think there's something stranger going on. I really am starting to doubt that pins A3 and B3 are right on the connector. But I thought I had previously confirmed that they work with a USB UART thing. But the oscilloscope's not seeing any traffic.
Let's go through using minicom to really control what we send via USB.
B3 really is data from the IceSugar Nano the USB. So that's good. But when I send to the UART over USB, I then expect the pin labeled A3 to show traffic. But right now it's not. Not a cracker.
Unless all my wonderful modifications to the power system has caused the trace to A3 to get broken. I've got another one here, so I can test. And the Pin Called A3 doesn't show traffic.
Right. So hopefully this is just a case of us working which pin it _is_ connected to. Well, the schematic claims it's pin A3 on the Lattice FPGA. But while I can see a trace from B3 on the board, I can't see any sign of any trace from A3. It _could_ be on an internal layer. But I'm not yet convinced.
If I had a steady enough hand I could continuity test to the UART pins on the APM32F103TBU6... which I managed to do, and found the two pins labeled A3 and B3 are connected to adjacent pins on that IC, which is what they should be. So why I can't I see traffic from the USB port coming onto A3?
The problem here is that while I can see the FPGA->USB UART traffic, I can't see the other direction on the adjacent pin. Now the pin pitch of this little IC on the board makes i quite difficult to probe by hand. But absent any test points, I don't have much choice.
The IC has 9 pins a side, and pin 1 is marked with a white spot on the board:
Is there some wacky coating on the pin stopping me from probing it? Or is it actually on a different pin?
Because right now I'm going insane: Schematic says FPGA pin A3 is the right one, and indeed, the FPGA receives UART traffic on it.
But neither the PMOD header nor the appropriate pin on the APM32 show any sign of being connected to it.
It _looks_ like they're the right pins.
So is there something wrong with my oscilloscope that it can't detect a single edge or two? But mashing keyboard into minicom also shows nothing up.
... And the pins are so close to each other, that I've managed to bridge them, just by poking a probe onto them a few too many times.
So back to using the one in the machine and _not_ trying to probe those pins.
So this problem is the RX direction into IceSugar Nano. There is pin C5 on that same PMOD that's currently being used for an extra power control circuit. There is pointedly nothing on there right now, so I'm going to stop wasting time, and just reuse C5 as a second UART RX pin.
Of course I could be jumping at shadows here, and it could be that the circuit works fine, and it really is my oscilloscope that's the problem. So let's go back to running megacom, and seeing if the USB-instigated traffic on the UART shows up at the buffer.
And, yes, something comes through. But it's appearing as garbled characters, although it's set to 115,200. I just recompiled megacom in case the version I had still had the out-by-one divisor bug. But no luck.
Okay, so with another USB UART for testing, it looks like the output from the 74HC244 is rubbish.
So, I've got myself so confused with everything that's going on here, that now I'm looking on the wrong UART connector in the MEGA65 for the power management UART. The power management UART should be on the keyboard UART breakout, not the PMOD one. And I think that one just has the UART polarity reversed...
And finally _something_ works! The MEGA65 can hear the power management UART now, and shows good solid signals.
And the other direction will probably work if I make that change to allow C5 to be UART input. But before that, let's see if the MEGA65's UART wiggles the pin A3 on the IceSugar Nano board when it's UART sends. If it does, then it is evidence that my oscilloscope is not the problem with whatever The Mystery of Pin Called A3 is on the Sugar.
Well, no. Because the pin from the MEGA65 keyboard connector is showing GND all the time. Which after all the insanity is almost reassuring. So let's see where the plumbing is broken for that in the core.
Hmm. Looks all fine. And the MAX10 should be passing KB_TDO straight through, which is what we're using here. That's pin 7 on the keyboard connector. Unless the MAX10 doesn't provide a pull-up? But then it would be floating, rather than looking like it's being driven low.
Hmm. Looks like polarity should go the other way. KB_TDO is from the main FPGA to the MAX10, and then out to the keyboard according to https://github.com/MEGA65/mega65-r2-max10/blob/master/top.vhd. So that would be our UART TX from the MEGA65. And of course it worked on the R6, because there's no MAX10 in the way... Okay, so time to rebuild the bitstream after fixing this for all targets.
Nope. Something's still messed up, because now I don't have either direction working on the keyboard port UART interface.
So how did it work in one direction before? Or is it that the MAX10 FPGA has an old version that had it messed up? Of course the battery in the prototype has just gone flat. So time to charge it up. In theory I can run it while it's charging...
Except I've probably killed those two cells by over discharging them. I should have thought about low-voltage isolation even for this prototype. My own fault there. I do have more of the cells, though, fortunately. But I might just disconnect the batteries and feed it from a bench supply to get me out of immediate trouble.
Or with the batteries connected, and bench supply set to a safe 3.33V that won't fry the LiFePO4 cells.
Well, with the batteries connected, the 3.3V rail isn't coming up. It's sitting right down on 0V. The 9V rail is trying to come up, but doesn't.
I left it all sitting long enough, and now it does come up again. It also draws 3.24A (okay, so the batteries are hopefully sucking some of that), but that would certainly explain how my 20Ah battery setup went flat over a few hours. I really need a lower power LCD screen, as that's the biggest suck. The MEGA65 uses a whisker over 1A, and the panel uses another 2A in its 9V dimness. So not outrageously bad, but still.
Anyway, back to figuring out what's going on with the UARTs.
The PMOD one's my first line of attack. And I've just reproduced this weird problem where the oscilloscope doesn't see the TX line go low. But if I bridge it to the RX line, I have working UART loopback. Ah, PEBCAC strikes again: I had it triggering off the wrong channel.
Cool. That means that the PMOD UART works.
So now to that pesky keyboard connector one. There's one line floating high on that connector, but it shows no traffic when I send chars. So let's look at that MAX10 firmware version. It's 6F3CAAA7. That commit doesn't exist. I do recall there being something odd about reversed bit or byte order or something. The date on it's recent enough to be the latest. This is probably the board I used to develop it, to be honest.
Once I stepped back for the day, I stopped running around in circles and just made a bitstream that puts my line waggler on every pin on the keyboard JTAG, so that I can see which one gets through to the connector, if any. And one does.
It looks like kb_tdi we can drive as output on pin 3 of our little UART header on the keyboard connector. kb_tdo doesn't get driven on any, so that should be the one that we can read. Now to think about a simple bitstream that will let me test that and see whether we have full loop on the circuit or not. I'll get ChatGPT to code me up a little loopback detector that will blink the mainboard LEDs when the circuit is complete. Then we'll _know_ which pins to use, and can just build a bitstream that should. just. work. Finally.
I'll also get it to toggle kb_jtagen slowly, in case that's causing the MAX10 to switch the circuit. It _shouldn't_, because the MAX10 doesn't even use kb_jtagen in the latest firmware version, but I've had enough tail-chasing yesterday that I just want to be sure. It must be said that the ability of the LLMs to do some of this grindy-grindy VHDL now with a good degree of competence is a welcome advance.
So... so far I'm not seeing evidence of the UART return path on the keyboard connector.
Sweet! Finally confirmed that we have a complete path on the R3. Now fixing that in the R3 and other targets, and rebuilding a bitstream that should, finally, let me talk to the power management UART. And if it doesn't we can be confident that the problem lies elsewhere. First stop will be probing the pin with the oscilloscope, and briding it with the UART RX pin on that header to confirm loopback. It finally feels like I'm making positive headway again...
Bitstream's cooked and loaded. I just have to plug the LCD panel back in, because I had it disconnected while I look at reassembling the top of the unit today. Managed to wrangle the HDMI port into an accessible position instead.
A quick run-up with megacom and briding the UART pins on the keyboard UART header confirms we now have UART there working!
Now that we've got the keyboard UART allegedly working, it's back to dealing with the IceSugar Nano's UART mystery related to the A3 pin. I'll implement the C5 pin thing, so that we have a backup pin, move the lead in the header, and see if we don't get power management UART visible on the MEGA65 keyboard UART with the complete path. But first, the towels have to go in the dryer...
Towels in, and IceSugar Nano firmware patched to use both USB_RX and C5 as UART inputs, with some magic to detect if C5 isn't connected, and thus might be floating low. So now I move the pin on the header, and see if we can't get power management UART visible on the MEGA65 :)
So on to the celluar modem now. The cellular modem should be on and running. That's the first thing to check. Then there is a weird problem I remember where the cellular modem sometimes outputs rubbish because the level shifters from 1.8V to 3.3V are a bit rubbish. If that's the case still, I'll look at putting a pull-up on the UART TX line from the cellular modem.
First up, I see 0V on both the UART lines for this connector. I'll check what the buffer sees on it's input pin for the cellular UART TX line. Nothing. So obvious first question is whether the cellular modem is even powered on. In theory an easy question to answer, except as you can see in the last photo, the prototype is a bit... spaghetti like.
And there are antennae and batteries and all sorts of visual obstacles to look in the side. It appears to not be powered on. The barrel jack does seem to have 3.3V to it, in that the regulator it's being fed from has output on, and 3.3V present. But that doesn't mean the barrel jack hasn't got a broken solder joint or something.
Well, aside from any other potential problem, the power switch to the modem was set to off. So apart from the face-palm momemt with that, it now powers up nicely. To test the UART link, I'll have to put that part back together again, and have words with it. But I might as well test that the SIM card still works while it's open. Well, I can ring it (but not answer) when it's turned on, but not when it's turned off. So I'll take that as a yes. We only need to test inbound calls now, anyway.
I also tested again trying to recharge the batteries via the parallel bench supply at 3.33V, and that seems to be working, in that >2A is flowing instead of <0.4A when just the cellular modem was booting. So maybe I didn't fry the batteries. I won't go replacing them, just yet. And it's good to know that I have a way to charge them enough that the proper charger has a way to believe that they're not broken. I guess it's one of those self-correcting stuff-ups that the regulator I'm using has a lower cutoff voltage that's above the minimum safe voltage for the LiFePO4 cells. I'll take it.
So, back to testing the rest of this, I need to flash the fixed UART routing bitstream (I was just jtag loading it before), then load up megacom and see if I can talk to the modem. But first, the next load of towels needs to go into the dryer.
Right. Core flashing. Battery charging. And I know where my towel is.
Hopefully next stop is talking to the cellular modem via the UART :)
No immediate comms, which probably isn't a great surprise. I could have the PMOD UART header on backwards, for example.
Looking from the front of the board stack, the left pin of the 3-pin header is the MEGA65's TX, and the right pin is the MEGA65's RX -- connect a USB UART to those pins, and I have good communications. But I'm still not seeing anything on the header from the cellular UART. Both lines are showing 3.3V, which is kind of reassuring. The buffer of course can be doing bad things here, so let's check that we can see the MEGA65 waggling the right line into the buffer, and if it comes out the other side.
And now my oscilloscope is giving me grief again. It shows triggered, but the waveform stays flat. Yet stick my finger on the probe, and I can see it do things. Both channels and probes are doing it. Okay, found the problem with the horizontal position set point being well off the edge of the screen. Glad I wasn't going crazy.
Now, back to the cellular modem. I can get to the extension lead that connects to the header on the cellular modem board, so I'll un-tape that, and try talking via the USB UART I have here, as well as probe it via the oscilloscope. If it's no good at that point, I'll have to look further down towards the cellular board.
And, yes I can :) The orange and white wires on the plug are the ones we need.
And it looks like the power management FPGA is feeding the output from it's power management UART onto this connector. That's wrong. Let's figure out why. Well, it was because some wires got skewered onto the pins of the buffer bridging something. So we probbly need to check all that again. Let's see if we can get the output pin on the buffer to follow the UART from the MEGA65. Yes: The pin in position 2 follows. And briding the header gets us loop-back on the MEGA65 UART, so we're all good, in theory.
And suddenly it's working :)
I can talk to the modem to answer a call and everything. Playing DTMF over the circuit works, but audio gain to the ear piece is basically so quiet as to be inaudible.
Now, I did see a patch of the weird cellular UART problem going on. On the oscilloscope it looks like the low signal oscillating wildly to about VCC/2, which prevents reception of the characters. I'll tape everything up, and hope that it's just a transient from everything being a bit loose and free and easy.
Right. That's all taped into place. And of course now the power management UART isn't talking to the MEGA65 anymore. Let's see what's come loose there...
On the plus side, I can confirm that recharging the batteries actually worked -- disconnecting the bench supply, the MEGA65 stays on. But let's go finding that loose connection (hopefully).
The power management interface seems to be completely not connected: I can't send a power off command to it, and it's not reporting anything.
So, I can see comms from the power management modem arriving on the middle pin of the keyboard UART header, which I believe is right. But megacom's now showing it. Matrix mode is showing debug output from megacom that it's hitting a BRK instruction continuously. Yup. It's frozen. So let's try reloading it. Also the reset switch on the cartridge port breakout doesn't work. Ah, that's an R3 board limitation -- cartridge port reset line is output only. Oh well. I could wire something onto J20, actually, which I think is a dedicated reset switch header on the motherboard I'd completely forgotten even existed. Either way, I can remove the cartridge port break-out board now.
Ok, Now I can talk to the power management UART again. Poking at the wiring loom didn't trigger any odd characters, so hopefully my effort pushing everything into place worked. I'm still going to tape the connector onto the keyboard port, though.
Now I'm trying to see if it will turn on the MEGA65 when the modem rings. It doesn't. But it seems to power cycle it if it's on... Well, one problem there is that we turn off the /OE for the buffer for the cellular TX line to the power management FPGA. So for now we're going to have to leave that enabled, at the risk of some minor back-powering into the MEGA65 via the keyboard UART port. That only feeds into the MAX10 FPGA, so I don't see there being any significant risk.
Well, this looks promising for when I've fixed that bug, though:
2026-10-05 13:01:14 EVENT: Cellular event log (41 bytes):
RQ: "ccinfo",4,1,4,0,0,"rEdacTED",128
2026-10-05 13:01:14 INFO: End of cellular event log
2026-10-05 13:01:20 EVENT: Cellular event log (1 byte):
R
2026-10-05 13:01:20 INFO: End of cellular event log
2026-10-05 13:01:26 EVENT: Cellular event log (1 byte):
R
2026-10-05 13:01:26 INFO: End of cellular event log
Those "R"s are it saying that it detected a RING, and the Q is saying that it saw a +QIND command, which can provide caller ID or SMS information. So this is all looking very promising now! Let's fix that buffer handling bug...
Bingo! Now it turns on. But it is still doing this weird power cycling thing when it happens. And then it also just does it randomly sometimes, too. I think I'm going to make a gate command for the power on/off bytes, so that noise on the UART can't cause problems so easily. There's probably interference from the cellular modem RF and all sorts of horrors going on with my spaghetti loom.
So now you have to do { and } around the byte to switch power. It seems to work. Let's see if it gets wake on ring working without power cycling. Bingo! There's still something loose _somewhere_ but it's all working enough to prove the functionality: When the phone rings, it can turn on the necessary hardware modules.
I also found that if the battery is not connected, the peak current draw can be too high for my benchtop supply, which I think was causing some of the boot looping.
Well, let's pause to see where we're at and what we need to do from here.
We have the base of the unit approximately assembled, and the power management stuff is now working quite nicely. So it's probably time to load the telephony software on, and make it run by default.
The telephony software we got broadly working back here. So I just need to create a D81 with an AUTOBOOT.C65 file on it that is the FONEINIT.PRG program, I think. Then it should boot straight into the phone software -- and if the phone's ringing, let us answer it. Powering off after hanging up is as easy as pressing the BOOT physical button for a couple of seconds. More fancy power control via the UART interface we can do later. Likewise, having a precursor program to FONEINIT.PRG that starts up at BASIC instead of running FONEINIT.PRG if the boot button was used to power on, rather than a telephony event.
I'm now updating the src/telephony repository to build a FONEBOOT.D81 to go in the root dir on the SD card that can be selected as the boot disk. That, in turn has entailed making an improved c64/c65 mode wrapper that can handle the variable entry points of LLVM-MOS compiled programs.
So what we might work on while I have an LLM making the auto-wrapper, is a FONEBOOT.PRG that checks if the power came on because of a phone event, or because of the power button. If the former, then it launches FONEINIT.PRG, but if it was the power button, then it just drops to BASIC _unless_ the P key is held during boot, in which case it still loads the phone. So the fun here is that we want to drop the M65 BASIC not C64 BASIC in this situation, so we might want to stash a magic value in colour RAM somewhere that tells the thing if it's already tried to boot this time around, so that it can do the SYS back to C65/M65 mode. It would be nice if on return to C65/M65 BASIC that when it tries to boot that second time, it erases all the LOADING etc lines, and prints a simple info message "HOLD P ON BOOT TO ENTER TELEPHONE". That would probably need to be done from the C65 mode part of the program, since otherwise if we use our C65 to GO64 mode wrapper, we'll be back in C64 mode. Sounds a bit convoluted. Is a bit, but not too badly so. It just means that this will be a C65-mode program that contains a C64 mode program that does the actual launching. So perhaps we have foneboot64.c that does the part in C64 mode, that gets launched by the foneboot65.c program if the magic value isn't sitting somewhere appropriate in colour RAM (eg at $FF807F0, where nothing else should be doing things at boot). If the magic value's there, then foneboot65.c uses KERNAL print routines to tidy the screen up, prints it's "PRESS P FOR PHONE" message, clears the magic byte from colour RAM, NEWs itself away, and drops to the READY. prompt as if nothing unusual had happened.
While my AI minions are working on that, I'll solder on that reset header to the R3 board here, so that I can make the reset button work. And also an extension for the CF backlight lead that is stupidly short. It also has to carry ~1.5KV max, so I've got three layers of heat shrink over the extension.
And somehow the reset button _still_ doesn't work. I think because my soldering on the GND pin wasn't good enough, because the ground plane sucks heat, and I didn't want to have to take the board out, so just did it from the top. But any other GND pin should work... Yup. Poor solder joint. I'll live without it, since the BOOT button gives us most of the benefit of reset, and the rest you can get with MEGA+TAB, then ! and RETURN.
The backlight extension works well, though.
The AI minion is still working on the FONEBOOT.PRG program I described earlier. Once that's ready, I'm keen to try the whole sequence of computer off, ring, and it turns on, loads the telephony program, and offers for me to answer.
Meanwhile, I might start assembling the screen bezel etc, now that the CF backlight lead is long enough. And I have that all nicely assembled:
There's also something sensitive in there that can cause the IceSugar to shut down or lose power. Not sure which, yet. But it certainly resets. But that can wait. For now, I'd just like to get the power management UART talking again.
Good news: The weird sensitive thing was just the power pin to the IceSugar being loose in the header. A gentle push of it firmly into place, and now I can breath on the IceSugar without power dropping out to the MEGA65.
Now that I'm digging into the power management UART, it is of course working. But it did briefly do TX from the MEGA65, but not respond. So if it happens again, my suspicion will be on the path to rather than from the MEGA65.
Okay, it's all screwed back together and both UARTs are still talking to me, and the thing isn't turning itself off -- so that's that fixed. Now to try to drop it into the case, and see if it still works...
Well, I have it in the box now, and it all starts up, and I can talk to the two UARTs :) So that's the final evidence of all the work on the case.
All that's left now is to demonstrate the telephony software starting up and being ready to answer an incoming call.
And I can indeed start the phone software from GO64 mode. I'm now working on fixing running it from the C65/C64 mode wrapper. It launches, but the video's all goofed up. So time to play spot the differences with VIC-IV registers. And the problem is solely that $D030 doesn't get cleared by the wrapper.
But first, some pictures of it assembled and running the telephony software:
Source, wiring loom diagram etc in the usual repositories:
No comments:
Post a Comment