P2D2 trials and tribulations update
Peter Jakacki
Posts: 10,193
Where where where have I been?
But before I begin, I sincerely apologize to all those who have been waiting for a P2D2, especially those who didn't have access to a P2.
To keep it short I've been too run down and stressed to even talk to anyone, which can happen very easily ever since my chemo (and still) it seems. Perhaps the stress is from trying to get these p2d2s assembled and just right but shipped yesterday!. There have been quite a few rejects and even when my pcb assembly friend has been available there were still many problems and too many delays.
Since this pcb is so packed it makes it hard to rework and also tiny QFN packs with tiny corner pads on the USB chip don't help either. Even the switching regulator doesn't always sit right on the board and trying to rework it gently can result in a damaged board. It's a tight little corner I painted myself into.
So for the last few months I have been doing a lot of software and some hardware testing, kinda waiting for an opportunity to get my pcbs assembled by my friend who has been very busy otherwise.
But now in the last few weeks I've been busier than a one-armed bricklayer in Baghdad, reworking pcbs and analyzing what is going wrong. I've made changes to the pcb to make it more manufacturable. However I spent way too long on the USB chip as this is mostly in jmg's hands and it seems that the USB serial library from Silabs has a few bugs that only I seem to uncover. It scrambles USB>UART data under certain conditions which jmg can't reproduce and I can very easily (and prove it is the ub3 too)
(Update: jmg confirms problems, but I have a version that never seems to play up at 57.6k baud).
Originally the chip I designed in wasn't going to do USB, just handle reset and a few other things Then I was swayed to the dark side with a USB capable chip instead. This is fine really except I really had to squeeze things in there plus I didn't want to be bogged down with USB serial firmware, which I left to jmg. Now I am ripping out that otherwise good chip from the board and putting usb on a little pcb module that mounts over the same place, but using a CP2102N for USB serial with the option to upgrade it back to the ub3 later because if it is reliable, it will be much better.
So I will have another micro on the main board in its place, probably a little XMC1100 in a TSSOP16 pack which is much easy to rework if necessary, but less likely to need it. Plus it has 64K Flash and 16K RAM and I can load it with a version of Forth and simply reprogram it from a P2 I/O all without ever having to touch one bit of ARM assembly language on it. Support micro firmware problems solved!
I will also produce the P2PAL pcb (and P2LAB) at the same time and it will also have USB serial on it, so I can use this as an option instead of the tiny usb pcb perhaps. Anyway, I'm giving myself options and getting a few different versions of the bare pcb made and an improved stencil too. I expect to finalize all the revisions and have them sent out sometime next week.
In the meantime I am sending out some of these P2D2s I have although I don't want to assemble anymore of this version unless I have to. I find the USB serial works reliably for me and TAQOZ at 57600. I can push it much faster but if I do it eventually it glitches somehow and scrambles rx data so that instead of 1234 it receives it as 2341. TAQOZ can be really hard on USB serial!
I can send out the current r4 boards to those who want them now. The enhanced r5 may take a few weeks longer but I expect them to be easily assembled and to have no production impediments and easy to rework if they aren't quite right.
Rev 5 of the P2D2 will have these little changes:
Better SMD pads and tenting of vias around the switching regulator (and UB3 USB r4A version for testing).
USB to be moved to a tiny rider PCB that sits in the same place but connects to the main pcb via a 5-pin header, a bit like a built-in PropPlug with a micro USB connector, but snug and tight.
On the main pcb in place of the old USB stuff I will have a tiny 16 pin TSSOP micro that will do this:
Drive P2 RESET high through a resistor. The P2 reset is normally pulled low as default and cannot start-up unless it gets the all-clear from the monitor micro which also looks after brown-outs and slow ramps.
P2 RESET CONDITIONS:
1.8V drops below a threshold
Reset button is pressed or external reset.
USB DTR is short pulsed during normal serial load operation (not just on change)
Watchdog timeout - (off by default until user triggers it - see commands)
ALSO:
If a valid DTR pulse is detected it will then also pullup P59 for a second or so to disable Flash and SD booting.
If the reset button has a long press it will pullup P59 for a reset into serial or ROM.
AT POWERUP:
Load I2C Si5351A Clock Gen configuration
SERIAL COMS FROM P2 COMMANDS:
- RESET P2
- SD POWER ON
- SD POWER OFF
- SD POWER RESET
- READ VDD VOLTAGE (1.8V)
- READ TEMPERATURE
- READ VREF
- RETRIG/START WATCHDOG (off at reset)
(optional but easy to do)
- READ/WRITE SPI FLASH
- READ/WRITE SD FLASH
- READ/WRITE I2C
BTW, TAQOZ has had massive updates which resulted in a new memory map and code that smoothly exceeds the 64kB limit and the new image footprint by default is 128k although loading everything and the kitchen sink hasn't exceeded 55kb yet. I had to force code to compile elsewhere to test this though. Proper vocabularies have been added which is important for verbose dictionaries such as TIA, the interactive P2 assembler. There are a lot of other enhancements too. TED, the screen editor is next which will result in a completely stand-alone system where I can assemble a whole new kernel if necessary. The system will have a backup mechanism via the support micro in case I manage to brick the P2 boot firmware.
But before I begin, I sincerely apologize to all those who have been waiting for a P2D2, especially those who didn't have access to a P2.
To keep it short I've been too run down and stressed to even talk to anyone, which can happen very easily ever since my chemo (and still) it seems. Perhaps the stress is from trying to get these p2d2s assembled and just right but shipped yesterday!. There have been quite a few rejects and even when my pcb assembly friend has been available there were still many problems and too many delays.
Since this pcb is so packed it makes it hard to rework and also tiny QFN packs with tiny corner pads on the USB chip don't help either. Even the switching regulator doesn't always sit right on the board and trying to rework it gently can result in a damaged board. It's a tight little corner I painted myself into.
So for the last few months I have been doing a lot of software and some hardware testing, kinda waiting for an opportunity to get my pcbs assembled by my friend who has been very busy otherwise.
But now in the last few weeks I've been busier than a one-armed bricklayer in Baghdad, reworking pcbs and analyzing what is going wrong. I've made changes to the pcb to make it more manufacturable. However I spent way too long on the USB chip as this is mostly in jmg's hands and it seems that the USB serial library from Silabs has a few bugs that only I seem to uncover. It scrambles USB>UART data under certain conditions which jmg can't reproduce and I can very easily (and prove it is the ub3 too)
(Update: jmg confirms problems, but I have a version that never seems to play up at 57.6k baud).
Originally the chip I designed in wasn't going to do USB, just handle reset and a few other things Then I was swayed to the dark side with a USB capable chip instead. This is fine really except I really had to squeeze things in there plus I didn't want to be bogged down with USB serial firmware, which I left to jmg. Now I am ripping out that otherwise good chip from the board and putting usb on a little pcb module that mounts over the same place, but using a CP2102N for USB serial with the option to upgrade it back to the ub3 later because if it is reliable, it will be much better.
So I will have another micro on the main board in its place, probably a little XMC1100 in a TSSOP16 pack which is much easy to rework if necessary, but less likely to need it. Plus it has 64K Flash and 16K RAM and I can load it with a version of Forth and simply reprogram it from a P2 I/O all without ever having to touch one bit of ARM assembly language on it. Support micro firmware problems solved!
I will also produce the P2PAL pcb (and P2LAB) at the same time and it will also have USB serial on it, so I can use this as an option instead of the tiny usb pcb perhaps. Anyway, I'm giving myself options and getting a few different versions of the bare pcb made and an improved stencil too. I expect to finalize all the revisions and have them sent out sometime next week.
In the meantime I am sending out some of these P2D2s I have although I don't want to assemble anymore of this version unless I have to. I find the USB serial works reliably for me and TAQOZ at 57600. I can push it much faster but if I do it eventually it glitches somehow and scrambles rx data so that instead of 1234 it receives it as 2341. TAQOZ can be really hard on USB serial!
I can send out the current r4 boards to those who want them now. The enhanced r5 may take a few weeks longer but I expect them to be easily assembled and to have no production impediments and easy to rework if they aren't quite right.
Rev 5 of the P2D2 will have these little changes:
Better SMD pads and tenting of vias around the switching regulator (and UB3 USB r4A version for testing).
USB to be moved to a tiny rider PCB that sits in the same place but connects to the main pcb via a 5-pin header, a bit like a built-in PropPlug with a micro USB connector, but snug and tight.
On the main pcb in place of the old USB stuff I will have a tiny 16 pin TSSOP micro that will do this:
Drive P2 RESET high through a resistor. The P2 reset is normally pulled low as default and cannot start-up unless it gets the all-clear from the monitor micro which also looks after brown-outs and slow ramps.
P2 RESET CONDITIONS:
1.8V drops below a threshold
Reset button is pressed or external reset.
USB DTR is short pulsed during normal serial load operation (not just on change)
Watchdog timeout - (off by default until user triggers it - see commands)
ALSO:
If a valid DTR pulse is detected it will then also pullup P59 for a second or so to disable Flash and SD booting.
If the reset button has a long press it will pullup P59 for a reset into serial or ROM.
AT POWERUP:
Load I2C Si5351A Clock Gen configuration
SERIAL COMS FROM P2 COMMANDS:
- RESET P2
- SD POWER ON
- SD POWER OFF
- SD POWER RESET
- READ VDD VOLTAGE (1.8V)
- READ TEMPERATURE
- READ VREF
- RETRIG/START WATCHDOG (off at reset)
(optional but easy to do)
- READ/WRITE SPI FLASH
- READ/WRITE SD FLASH
- READ/WRITE I2C
BTW, TAQOZ has had massive updates which resulted in a new memory map and code that smoothly exceeds the 64kB limit and the new image footprint by default is 128k although loading everything and the kitchen sink hasn't exceeded 55kb yet. I had to force code to compile elsewhere to test this though. Proper vocabularies have been added which is important for verbose dictionaries such as TIA, the interactive P2 assembler. There are a lot of other enhancements too. TED, the screen editor is next which will result in a completely stand-alone system where I can assemble a whole new kernel if necessary. The system will have a backup mechanism via the support micro in case I manage to brick the P2 boot firmware.
Comments
There are certainly some tiny parts now available, that do amazing things. Can't help think we need occular implants to prototype them, though.
Thank you again for Taqoz and all of your job - it is a tool with tremendous power and a joy to program with once you make your head around The Forth.
About the P2D2, I'll go with the two ordered if there are enough boards from @ErNa, I don't really need a fast USB on those that have to be embedded in some test systems.
Your contributions are always valued.
Im amazed what your projects go to
Rev 5 sounds like a winner!
whenever you can give a total price for the rev5 bundle to europe
I wilĺ paypal to eventually start with p2 as well.
and all the best for your health.
I will let him tell his side of that if he likes, but right smack bang in the middle of me coming to grips with new support micro replacements this has caused me to rethink this for a moment. I asked him if the UB3 could have a simple I2C slave function and also smarter reset button action. While I wait for him to ponder that I will make an A version of r4, perhaps it will then be the r5 instead which controls P2 reset directly and fixes up some of the other issues. This I can have ready to send off tomorrow. This current version can still do smart reset though which validates the DTR pulse and forces the P2 into serial mode for loading, and where a long press of the reset button can also cause it to bypass Flash/SD boot allowing quick access to the ROM.
Man, this is going too far, so I went to 24Mbd with a code of 1 and then it was garbled. Finally!
But wait, it recognized input, only the output was garbled. That could be something to do with the drive level. When I type WORDS it responds with lots of garbage, but it responds. So I will find out what is happening on the scope and fix it if I can. Imagine that, a serial port that works at 24Mbd! Even if the throughput for it isn't there, it's still a huge plus.
There are some caveats here I will expand on :
UB3.Tx can work faster than UB3.RX can, and you can set UB3.TX all the way up to 24Mbd, but it cannot quite Rx at that speed, as there are not enough sample slots per bit.
12MBd UB3.Rx will be marginal, as that has 4 samples per bit, but it might be ok some of the time
I've found 6MBd and 8Mbd are looking reliable with 2 stop bits, in packets of up to a tad over 1536 bytes (the on chip Rx buffer) Below 6MBd 1 stop bit is ok.
When sending long sustained streams, you need to keep under the PC+USB VCPxpress limits, which are in the 3~4Mbd ball park.
UB3.TX will self limit, without dropping characters, but UB3.RX will simply over-run as there is no handshake.
Any Baud value of the form 24M/N is legal, and current silabs release driver has a regression, that needs N to be entered for > 1MBd (That's why Peter is using 3 & 2 above to set 8MBd and 12MBd)
But it definitely works at 12Mbd. I've downloaded code into it without any line delays and this is when I ask it to list its dictionary at that speed (in the blink of an eye) and it seems fine.
What you need is just 10^4 times that
I checked that again, and I can send a packed 1536 bytes via FT232H, using 2 stop bits, which takes 1408us at 12Mbd, and UB3 receives that packed burst ok, into the large Rx Buffer. (these are half duplex tests)
Checking with 1 stop bit confirms it drops characters, so 12M.8.n.2 is needed
That dictionary is about 7760 bytes, so it must have some inter-char delays, meaning those are not packed. The driver + USB pipeline can sustain about 4Mbd averaged, but the UB3 can accept moderate (~1536 max) bursts at 12M.8.n.2
The first modem I designed did 1200 baud hdx sync for mainframes 2780 bisync. Loooong time ago
I didn't realize your P2D2 efforts have been so challenging, with personal health and stress mixed in. Everything you described about hardware development is a familiar part of the process I have come to know at Parallax. Just this afternoon I was talking with Chip about expectations around P2 accessory boards, and how expensive/consuming it is to make an electronic product. Sometimes these designs also get unnecessarily complicated to support every possibility, but with very little gain to the developer. I'm sure you've spent a thousand hours on P2D2 and expectations for this little board will be $30, common to most PCBs this size.
Many forum members are interested in the outcome, so stick with it - but not at the expense of stress.
We are expecting Rev C chips soon and I will see that we get some off to you at the earliest possibility.
Ken Gracey
1) Pull-down on P2 RESn with active drive from UB3 (no power-up/down or brown-out hiccups)
2) DTR load pulse validation - simply opening and closing ports etc will not trigger a reset.
3) Valid DTR load pulse enables P59 pullup thus forcing serial load mode regardless of SD and Flash bootability
4) Short reset press = normal boot ; long reset press = disable Flash and SD boot (enter TAQOZ ROM or debugger etc)
5) Reset button and external reset actually disable SDON which cuts the SD power and is sensed as a reset request by the UB3
There are a couple of other things we are sorting out, but it looks like I may be able to use the UB3 both as USB serial and support functions.
Certainly the fact that new firmware can be loaded over USB is a feature although this is normally only done once.
The auto P59 pullup on valid DTR pulse means that I can leave my bootable SD card inserted and still load up the board serially.
I've tested this on PNut34s and instead of loadp2, I have using OzPropdev's Python P2 loader which I have just abbreviated to loadp2.py. This loader seems to work a bit better in terms of timing with this DTR load pulse validation.
I also noticed that I used to get some RTC corruption on power-up sometimes, but now with these mods which keep the P2 in reset until the UB3 says go, the RTC doesn't glitch. Even if the UB3 hasn't booted or can't because the voltage is too low, the pull-down resistor on P2 RESn stops it from trying to run (and do whatever).
Item 4 with the reset button isn't quite right yet in the firmware, it's the other way around, but a short press or external pulse should always cause a normal reset. So that will be fixed or left as a normal reset.
BTW, the UB3 firmware can be reloaded by forcing a UB3 pin low on plug-in. I'm going to try and bring that pin out on r5 just to make it that bit easier if it ever needs reloading. At present I solder a tiny button to the top of the USB connector as ground and the other leg has a short wire going to the UB3. Press the button as you insert the cable and it uses the internal USB HID bootloader.
Once I am convinced that it will do what it needs to, then the r5 artwork will be sent off. This means r5 won't look much different, with the same USB. Nonetheless, I will have an alternate version available anyway, as well as the P2PAL and P2LAB boards about 3 weeks away now from being assembled and ready to ship.
Baking (make and burn) TAQOZ on Linux (with a bootable SD still in)
To clarify Peter, is the alternate version you mention in this quote above the one without the USB chip on the main board, ie. on a separate rider board attached to the top? I'm still a bit confused with all these changes that have been discussed. It sounds like you've got the USB going at least and now intend to keep it on r5 main board which was different to your plans before the recent breakthrough.
In my case I'm keen to get some on USB board serial capability to operate the board standalone initially and my enclosure is height constrained as well, so extra add on rider boards may not be that ideal for me. Also I need to drive out TX/RX and reset (which I'd tri-state / pull low) from my own system board into the P2 as well, for both re-programming and run-time serial access, so hopefully these don't interfere in normal operation if your USB port is not used once the P2D2 gets fitted inside my enclosure. That would be a preferable way for an embedded P2D2 to operate when fitted in another system board in general so people don't lose main serial access and can still control reset if they need to.
The P2PAL still sounds good and I'm happy to wait for that too, now you are back on it. I'd definitely be keen to see how that design goes and its final size etc because it may save me trying to get some HyperRAM fitted on my own board which won't be nearly as ideal with the extra wiring lengths and extra connectors it would be passing through that way. In comparison your P2PAL HyperRAM signal traces should be much shorter.
So now I've decided that the support functions are reliable and sufficient for now, plus the UB3 firmware can be upgraded via USB in the future. But I have to decide if I use the existing boards since I don't want to hack them I would need firmware that used the existing reset pullup method.
Therefore, this week I intend to send out the r5 artwork using the UB3 as it is now with the new firmware and the reset and pcb changes mentioned. So as not to delay anything else any further I will get the P2PAL and P2LAB at the same time and also an alternative P2D2 with a separate support micro and USB serial, just for testing at this stage, but also as a backup or future model.
BTW, the rider pcb I mentioned last time is not riding above the height of the whole pcb, just above the pcb itself, so only slightly elevated. The support micro is buried beneath it.
One mode the UB3 is tested in, is power-only USB cables.
The reset push button works in both power-only USB cable, and full USB cable modes, so that means from our own system board, you can control std-boot, or force-serial boot (revised to short / long (>1s) reset widths)
Under investigation is allowing DTR widths to control Serial Boot (default short), or flash boot, or SD Boot, which may be useful for close-case / more remote type developments.