Murphy's law: On oscillator circuit never oscillates. An amplifier circuit oscillates immediately.
Very long tiome ago I also had all sorts of problems with crystal oscillators. Broken crystals (dropped on the floor or smashed by the P&P machine), oscillators not oscillating at all or requiring too much start-up time, too much overshot, too much damping, 3rd overtone oscillators running at the base frequency, base frequency oscillators running at an overtone frequency... this is probably why many electronics engineers are scared by oscillator circuits.
BUT... I never had a single case where the oscillator didn't work with a Propeller, neither with the P1 nor with P2. It just works. No need to worry.
@rogloh said:
.... I'm seeing some weird startup delay too once the external PLL is activated. It's like if and when intermittently it does download and run the code enabling the PLL, it then takes a few extra seconds or so to switch over to the crystal and then output the application's serial port response data I send out at bootup (even when I put no startup delays in the code). In comparison P2-EDGE board does not do this and outputs data immediately after the binary download has finished. There is some flakiness in the PLL's startup time on my board, potentially soldering related but it could also be something else like load capacitance perhaps if the PLL takes longer to lock.
I hope it is not supply/noise related on the VCCIO supply for the PLL. I'm seeing ~20mV RMS of noise (~80mVp-p) on the board's 3.3V supply, and similar on 1.8V regulator output if I can trust my scope's built-in measurements. Same amount of noise seems to be present on the VCCIO for pins 28..31 (PLL supply).
Seconds of delay is a long time - is the delayed output free of garbage, and as expected ?
P2 has no PLL lock detector, so there is no gateway like that.
You could toggle a pin, and probe the XO pin (even via a moderate 1~2k resistor to lower C loading effect ) and that should allow checking of Osc startup, and PLL change overs.
as a guide, here are some Startup times for various brands of 48MHz Crystal oscillators I measured : 220us 100us 150us 1.4ms 3.88ms
@Yanomani said:
If excessive stray capacitance is to be blamed as a possible cause of any problems, you can simply rule out the internal caps, by attempting a CC-field stuffed with %01, as part of the hubset command composition.
Yes I might try that when I get onto this work later to see if it changes anything.
@ManAtWork said:
BUT... I never had a single case where the oscillator didn't work with a Propeller, neither with the P1 nor with P2. It just works. No need to worry.
Great, that gives me some further encouragement with getting this up and running.
@jmg said:
Seconds of delay is a long time - is the delayed output free of garbage, and as expected ?
It seems to print the string without garbage yes, just delayed more in time after the download. The delay when running on this board and the P2 EDGE setup was readily apparent and I tried it a few times.
You could toggle a pin, and probe the XO pin (even via a moderate 1~2k resistor to lower C loading effect ) and that should allow checking of Osc startup, and PLL change overs.
Yes good idea. What I will do is measure the time between the end of the serial download on P63 and the beginning of an IO pin toggling using my logic analyzer. I'll also run this same test on the P2-EDGE setup for comparison using the same binary. That should really determine any real startup delay differences and not simply rely on observing serial response delays using loadp2 on my Mac.
Here was the test program I ran last night, hacked up from Cluso's original pin check program. In fact it already has some pin toggling code in there. It was on my mind to use this to make sure the P2 frequency was correct in case I encountered baud rate issues and nothing readable got output back to loadp2's terminal.
CON
_clkfreq = 200_000_000 ' clock frequency
'_rcfast
_BAUD = 115_200 ' serial speed
LOPIN = 0 ' lowest io pin to be tested
HIPIN = 57 '61 ' highest io pin to be tested
DLAY = 100 ' delay after setting pullups/pulldowns (>=25/35)
rx_pin = 63 'pin serial receiver
tx_pin = 62 'pin serial transmitter
OBJ
term : "jm_fullduplexserial" ' serial terminal
VAR
long errors
PUB test()
pinlow(0)
pinhigh(1)
term.start(rx_pin, tx_pin, 0, _baud)
term.fstr0(string("Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...\r\n"))
repeat
pintoggle(2)
waitms(500)
@rogloh said:
Here was the test program I ran last night, hacked up from Cluso's original pin check program.
I would continually toggle a pin, with no pauses, as you are looking for possible clock dropouts here.
You can also switch to XTAL clock source, with no PLL, if you need to divide the problem further.
Hmm, it's not doing this delayed output problem anymore today and starts up right away now, although I still need to use the -SINGLE option in loadp2 to load anything and can't ever load fast which means the clock source/PLL might still be having trouble switching in time for the second stage download. Still looking into that aspect. This morning I'd soldered on some pin header connectors plus another 0.01uF bypass cap on VCCIO for P28-31 and also cleaned the board again before testing again. Maybe some of that somehow helped. It was definitely happening yesterday so I'm not sure I fully trust it yet.
@Tubular said:
Wow good to see that project back again and moving forward
Remind me again which RTC you used? I need to choose an RTC...
It was a Microchip RTC part. MCP79401. Not as fancy as that one that Peter had on the P2D2 but probably more available and easier for me to solder though it needed another 32kHz crystal. It also included some battery backed SRAM and an EUI-48 MAC address in EEPROM which at one time I thought could come in handy in this application.
BUT... I never had a single case where the oscillator didn't work with a Propeller, neither with the P1 nor with P2. It just works. No need to worry.
You have built a lot more than me, but I have never had a problem with using xtals on the P1 or P2. On P1 I use both HC49U/S xtals (5.00MHz, 6.00MHz and 6.5MHz - mostly 6.5MHz) and 3225 12MHz. On P2 I have only used 3225 20MHz xtals.
Looks like my board's download problems were loadp2 related. I updated to the latest loadp2 and can now download okay without the -SINGLE option and also at 2Mbps. It seems like some timeout values changed since the older version I had. Am still testing but both my P2-Edge and P2ME2 boards are behaving similarly now.
I do see some new loadp2 download problems with -SINGLE if the loader baud rate is not the same as the terminal baud rate. This happens on the P2-EDGE as well. It looks to be the same problem with not waiting long enough for the FTDI FT231 device's TX FIFO to drain before initializing the terminal console with new baud rate, and I'd hit this before. In this case the baud rate changes on the fly for the console somewhere in the middle of the data transmission before it completes, corrupting the binary download. I'd debugged this problem before and it begins to get mentioned here https://forums.parallax.com/discussion/comment/1463735/#Comment_1463735 also @jmg also had some related comments following that too.
There still might be some small amount of HW or crystal flakiness remaining but I will have to try to pin that down if it exists at all. I thought I saw a couple of binary downloads failed once after an initial board powerup then everything seemed to work many times in a row after that, so it's not totally proven yet. I'd like things to feel a bit more rock solid before I was confident in this board. It could still be marginal soldering affecting things, but at least I can now readily download code to the board at high baud rates (2Mbps) and start to test other code at full P2 speed etc. That wasn't really possible before fixing the loadp2 thing.
@rogloh said:
I do see some new loadp2 download problems with -SINGLE if the loader baud rate is not the same as the terminal baud rate. This happens on the P2-EDGE as well. It looks to be the same problem with not waiting long enough for the FTDI FT231 device's TX FIFO to drain before initializing the terminal console with new baud rate, and I'd hit this before. In this case the baud rate changes on the fly for the console somewhere in the middle of the data transmission before it completes, corrupting the binary download. I'd debugged this problem before and it begins to get mentioned here https://forums.parallax.com/discussion/comment/1463735/#Comment_1463735 also @jmg also had some related comments following that too.
Maybe a simple delay is too inflexible, (buffer sizes and baud rates all vary), so after download and before a baud change, maybe loadp2 could send a ping that gives a known echo, and wait for the echo before change of baud ?
Yeah jmg that would be a good feature to add to loadp2 to make it more reliable, as the buffer size is HW/platform dependent. It's likely fixed in the FT231 device used by the official REV E prop-plug and P2-EVAL board but what about older versions or other serial interface devices. Also there might be further USB driver software buffers in the PC/Mac that might add to the total buffer size of the transmit pipeline that needs to clear before waiting for the baud change.
I think it's probably just the -SINGLE option now that might just have this problem, not the default two stage downloader which does wait for a checksum/acknowledgment after each block transferred and if you miss receiving it you get those timeout errors.
Found another problem in loadp2 when running the two stage loader. It doesn't wait to drain the transmit buffer on Mac platforms after each block before it starts the timeout period for getting a response, it only compiles in the call to wait_drain() for win32 platforms. When I commented out the conditional #ifdef in this code so it would be included on my Mac it started working at lower baud rates like 28800 without a timeout error (not that you'd typically want to use that speed).
This is another loadp2 bug. @ersmith, did you want to fix that? Maybe it was meant to be #ifndef _WIN32 like the loadfile function had earlier in the file, but I think Windows platforms potentially would also benefit from this wait_drain call being implemented correctly (currently it just does a 30ms wait on Windows platforms).
Before the fix, the download will timeout:
$ loadp2 RBTest10.bin -t -l 28800
ERROR: timeout waiting for checksum at end: got -1
Fix in loadp2.c:
// receive checksum, verify it
int recv_chksum = 0;
//#ifdef _WIN32
wait_drain();
//#endif
num = rx_timeout((uint8_t *)buffer, 3, 400); <---- a 400ms timeout might not be enough at low baud rates if the O/S has large serial transmit buffers and you are not calling wait_drain to wait until the O/S has flushed them out.
After the fix the download works:
$ loadp2 RBTest10.bin -t -l 28800
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 25000000, clkmode = $0
Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...
Init Hi 1111111111111111111111111111111111111111111111111111111111
Test Lo 0000000000000000000000000000000000000000000000000000000000
Init Lo 0000000000000000000000000000000000000000000000000000000000
Test Hi 1111111111111111111111111111111111111111111111111111111111
Done 0....V....1....V....2....V....3....V....4....V....5....V....6...
Passed shorts test
Also in loadp2.c if you initialize use_checksum to 1, it does seems to work on my Mac OS X at least, and fixes the -SINGLE option problem I mentioned earlier by waiting for the "." acknowledgment from the P2 loader before dropping into the terminal and changing the baud rate which potentially corrupts the ongoing data transmission if the loader baud rate is different to the terminal console baud rate.
So it should be possible to change this line
static int use_checksum = 0; // 1 seems to fail on MACOSX, not sure why
@ersmith said:
@rogloh : I've updated the loadp2 git repository. I hope the version there now will fix your problems.
Thanks,
Eric
Thanks Eric. I'll update with your latest and retest. In the end I think had encountered about four total issues, and some needed to have different baud rates configured to be encountered. You can observe all these problems if you monitor the serial data lines with a logic analyzer or scope and see when it fails and compare with the expected data delays between transfers in the download sequence . Most of the issues seem to stem from the fact that on a PropPlug there is a USB FIFO holding characters sent to the P2 and that also needs to have time to drain, and the existing wait_drain() function we have is only waiting for the characters to leave the PC/Mac, but doesn't factor in the additional external FIFO drain time. A raw serial port delivering characters directly with no FIFO probably wouldn't have this drain time problem.
1) in -SINGLE mode, there was no waiting for any ack using the "." character from the Prop2 which meant it could continue on and change the baud rate prematurely to the console rate while the transfer was still in progress in the FIFO if the loader baud rate was low and different from the console rate. Enabling the "use_checksum" feature seemed to help this, however the timeout interval really needs to account for the additional USB FIFO drain time which varies with baud rate. Right now it was fixed at 100ms, but it could neeed to be as much as 5120/baud rate or 533ms down at 9600bps if someone used a really slow serial link transfer. I do think the timeouts should be computed based on the loader baud rate instead of being fixed.
2) in the regular two stage loader (CHIP) mode, there were 3 more issues:
a) with slow loader rates, the two first autobaud characters (0x55) can appear very early, immediately after the "~" char that ends the first stage download and this can cause an initial download timeout, even though you do retry and send them again up to 5 times. The first back to back autobaud characters after the ~ fail because the second stage loader code has not started in the COG at that time but I'm not yet quite sure why the repeated attempts also continue to fail but they can.
b) at slow loader rates there is a risk that the autobaud fails because the code doesn't first wait for the final 5th transition from 0 to 1 in the first autobaud character before trying to match the 0x55 in the next character and that last transition in the first byte corrupts the second byte matching (because of the start bit there are five 0->1 transitions in the autobaud character not four). As a workaround I added a small wait for two extra bit periods which seemed to help resolve this, as long as the second character it validates arrives later and not back to back when the loader rate is high, because then it doesn't give the autobaud function enough time to complete. It's somewhat tricky timing if the characters arrive back to back.
c) if the load rate is very slow, the 400ms checksum rx timeout per file portion downloaded is not still enough to account for the receive USB FIFO from emptying and the code can timeout.
Maybe for now we can assume a default 512 byte FIFO size (assuming a prop plug with FT231X) so the timeouts get computed based on this size and the loader baud rate, and then have an optional command line parameter to override this FIFO size in case people want to use other/future USB serial devices with larger FIFOs. Also if it does timeout with an error, loadp2 could then suggest to the user to increase the FIFO size parameter on the command line so people could have some control over what is happening there if needed.
Also I was able to get 3Mbps downloads working intermittently but the autobauding is very marginal at that speed with RCFAST. When autobauding works it can successfully download the remaining file at this speed on a Mac with FT231X in the Prop plug but it doesn't often succeed. There are not many P2 cycles available to measure the bit period at 24-25MHz the way it is done. If this check could be sped up it might be able to do 3Mbps more reliably. Maybe there is some way a smartpin mode can measure the bit period in hardware instead of timing it in software. Not sure. The -SINGLE option with 3Mbps is readily achievable but it sends 3x as much ASCII data as needed so it's still slower than what could be done with pure binary data at 3Mbps.
@Rayman said:
I've had occasional load issues just like this with my own custom boards too... Hope this fixes it.
It always works perfectly with Eval board though. Also, the Prop tool works perfectly with my own boards. Something strange there...
Do you use a Mac or PC? I first noticed this loadp2 timeout stuff when I used a PropPlug on a JonnyMac board. P2-EVAL worked fine but JonnyMac board had lots of timeout errors with an older loadp2 I had. Weird because both setups use the FT231X device. I wondered if it was due to small RCFAST differences somehow, if the rev B chips had different typical speeds vs rev C chips?
@rogloh said:
Also I was able to get 3Mbps downloads working intermittently but the autobauding is very marginal at that speed with RCFAST. When autobauding works it can successfully download the remaining file at this speed on a Mac with FT231X in the Prop plug but it doesn't often succeed. There are not many P2 cycles available to measure the bit period at 24-25MHz the way it is done. If this check could be sped up it might be able to do 3Mbps more reliably. Maybe there is some way a smartpin mode can measure the bit period in hardware instead of timing it in software. Not sure.
FWIR, the ROM loader using RCFAST does use smartpins to do the autobaud, and it measures over multiple baud-bits to get better precision.
Do you have other UARTs to try ? eg FT232H can do 24M/N, so 2.666667MBd is also valid.
@rogloh said:
Yeah fractional clocks would be handy, as there are only around 8 or 7 clocks at 3Mbps with 23-25MHz RCFAST and quantization error could be high.
I don't have other UARTs here no. I think Tubular probably has a good range of them including FT2232 etc.
I connected a P2Eval and ran some quick Autobaud ping tests, using ROM+RCFAST, using PL2303GC as that's the finest baud part I have easily connected.
8MBd always fails,
4.8MBd seems the highest reliable autobaud choice.
Quite a few baud values 'mostly' work. A more gradual failure curve than I expected ?
I do not have many boards to test loadp2 with, so I have to rely on bug fixes from the community. The best way to communicate these is to submit pull requests (or at least bug reports) to my loadp2 github repository.
@ersmith said:
I do not have many boards to test loadp2 with, so I have to rely on bug fixes from the community. The best way to communicate these is to submit pull requests (or at least bug reports) to my loadp2 github repository.
Yeah I will try to do that once I test it a bit more. I want to know why your retry code is failing. It's very easy to make happen with the loader baud rate set to 115200bps in CHIP mode.
@ersmith said:
I do not have many boards to test loadp2 with, so I have to rely on bug fixes from the community. The best way to communicate these is to submit pull requests (or at least bug reports) to my loadp2 github repository.
Yeah I will try to do that once I test it a bit more. I want to know why your retry code is failing. It's very easy to make happen with the loader baud rate set to 115200bps in CHIP mode.
Just trying some faster loadp2 checks ( on a Dec 2019 build as I cannot build from source) and I notice -SINGLE has fewer checks and seems to give false positives - it can report file loaded, with no verify or checksum
The two step loader reports more info and seems to include a checksum verify step.
Yes, jmg that is an issue. The latest code Eric added has improved this and has put in the wait for the "." char to be sure the file is loaded in SINGLE mode.
By the way I've just improved the autobaud in loadp2 by sending $80 instead of $55 and measuring clock period for 8 serial bit times being logic low (this is including the start bit) and then shifting this value up by 13 bits so fractional baudrates with the smartpin WXPIN parameter should now work. It also now lets me do 3Mbps which was not reliable before. Still testing but when I'm done I'll submit these changes to Github via a PR or do a bug fix post for Eric.
The other delay changes I put in seem to let me now load from 14400bps up to 3Mbps in both -SINGLE and the default -CHIP modes and I'm not seeing timeouts (yet). Going even lower down to 9600bps and below seems to need another change in the port detection timeout area. I might look at that too. I know that these baud rates would be very uncommon but perhaps some setups might have very slow serial links or something and it could still be useful to support.
Comments
Murphy's law: On oscillator circuit never oscillates. An amplifier circuit oscillates immediately.
Very long tiome ago I also had all sorts of problems with crystal oscillators. Broken crystals (dropped on the floor or smashed by the P&P machine), oscillators not oscillating at all or requiring too much start-up time, too much overshot, too much damping, 3rd overtone oscillators running at the base frequency, base frequency oscillators running at an overtone frequency... this is probably why many electronics engineers are scared by oscillator circuits.
BUT... I never had a single case where the oscillator didn't work with a Propeller, neither with the P1 nor with P2. It just works. No need to worry.
Seconds of delay is a long time - is the delayed output free of garbage, and as expected ?
P2 has no PLL lock detector, so there is no gateway like that.
You could toggle a pin, and probe the XO pin (even via a moderate 1~2k resistor to lower C loading effect ) and that should allow checking of Osc startup, and PLL change overs.
as a guide, here are some Startup times for various brands of 48MHz Crystal oscillators I measured : 220us 100us 150us 1.4ms 3.88ms
Yes I might try that when I get onto this work later to see if it changes anything.
Great, that gives me some further encouragement with getting this up and running.
It seems to print the string without garbage yes, just delayed more in time after the download. The delay when running on this board and the P2 EDGE setup was readily apparent and I tried it a few times.
Yes good idea. What I will do is measure the time between the end of the serial download on P63 and the beginning of an IO pin toggling using my logic analyzer. I'll also run this same test on the P2-EDGE setup for comparison using the same binary. That should really determine any real startup delay differences and not simply rely on observing serial response delays using loadp2 on my Mac.
Here was the test program I ran last night, hacked up from Cluso's original pin check program. In fact it already has some pin toggling code in there. It was on my mind to use this to make sure the P2 frequency was correct in case I encountered baud rate issues and nothing readable got output back to loadp2's terminal.
CON _clkfreq = 200_000_000 ' clock frequency '_rcfast _BAUD = 115_200 ' serial speed LOPIN = 0 ' lowest io pin to be tested HIPIN = 57 '61 ' highest io pin to be tested DLAY = 100 ' delay after setting pullups/pulldowns (>=25/35) rx_pin = 63 'pin serial receiver tx_pin = 62 'pin serial transmitter OBJ term : "jm_fullduplexserial" ' serial terminal VAR long errors PUB test() pinlow(0) pinhigh(1) term.start(rx_pin, tx_pin, 0, _baud) term.fstr0(string("Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...\r\n")) repeat pintoggle(2) waitms(500)I would continually toggle a pin, with no pauses, as you are looking for possible clock dropouts here.
You can also switch to XTAL clock source, with no PLL, if you need to divide the problem further.
Hmm, it's not doing this delayed output problem anymore today and starts up right away now, although I still need to use the -SINGLE option in loadp2 to load anything and can't ever load fast which means the clock source/PLL might still be having trouble switching in time for the second stage download. Still looking into that aspect. This morning I'd soldered on some pin header connectors plus another 0.01uF bypass cap on VCCIO for P28-31 and also cleaned the board again before testing again. Maybe some of that somehow helped. It was definitely happening yesterday so I'm not sure I fully trust it yet.
This PCB seems to fit nicely in my first target application at least.
"Like a glove!" - Ace Ventura
Wow good to see that project back again and moving forward
Remind me again which RTC you used? I need to choose an RTC...
It was a Microchip RTC part. MCP79401. Not as fancy as that one that Peter had on the P2D2 but probably more available and easier for me to solder though it needed another 32kHz crystal. It also included some battery backed SRAM and an EUI-48 MAC address in EEPROM which at one time I thought could come in handy in this application.
https://www.farnell.com/datasheets/2138500.pdf
One can only imagine how much fun the rest of this will be to hand solder!
LOL.
...
You have built a lot more than me, but I have never had a problem with using xtals on the P1 or P2. On P1 I use both HC49U/S xtals (5.00MHz, 6.00MHz and 6.5MHz - mostly 6.5MHz) and 3225 12MHz. On P2 I have only used 3225 20MHz xtals.
Looks like my board's download problems were loadp2 related. I updated to the latest loadp2 and can now download okay without the -SINGLE option and also at 2Mbps. It seems like some timeout values changed since the older version I had. Am still testing but both my P2-Edge and P2ME2 boards are behaving similarly now.
I do see some new loadp2 download problems with -SINGLE if the loader baud rate is not the same as the terminal baud rate. This happens on the P2-EDGE as well. It looks to be the same problem with not waiting long enough for the FTDI FT231 device's TX FIFO to drain before initializing the terminal console with new baud rate, and I'd hit this before. In this case the baud rate changes on the fly for the console somewhere in the middle of the data transmission before it completes, corrupting the binary download. I'd debugged this problem before and it begins to get mentioned here
https://forums.parallax.com/discussion/comment/1463735/#Comment_1463735 also @jmg also had some related comments following that too.
I think my fix was to have a delay/timeout of 100ms to help try to accommodate the extra TX fifo drain time, but @ersmith appears to have reworked this file on March 11 2021 and removed this delay in some of his optimizing so it might have been broken a while back (at least on a Mac platform, not sure about other platforms but it could possibly affect those too).
https://github.com/totalspectrum/loadp2/commit/0639538c49d8f0640a2e91772bce122c8d1c0ecf#diff-a9e33727f5ea54ef79cf066dbd61be2559a699acb9efa83c5e6286575356f51b
Ok its great you got that sorted because my mind was running through all the hardware related possibilities. Nothing like a software fix!...
There still might be some small amount of HW or crystal flakiness remaining but I will have to try to pin that down if it exists at all. I thought I saw a couple of binary downloads failed once after an initial board powerup then everything seemed to work many times in a row after that, so it's not totally proven yet. I'd like things to feel a bit more rock solid before I was confident in this board. It could still be marginal soldering affecting things, but at least I can now readily download code to the board at high baud rates (2Mbps) and start to test other code at full P2 speed etc. That wasn't really possible before fixing the loadp2 thing.
Maybe a simple delay is too inflexible, (buffer sizes and baud rates all vary), so after download and before a baud change, maybe loadp2 could send a ping that gives a known echo, and wait for the echo before change of baud ?
Yeah jmg that would be a good feature to add to loadp2 to make it more reliable, as the buffer size is HW/platform dependent. It's likely fixed in the FT231 device used by the official REV E prop-plug and P2-EVAL board but what about older versions or other serial interface devices. Also there might be further USB driver software buffers in the PC/Mac that might add to the total buffer size of the transmit pipeline that needs to clear before waiting for the baud change.
I think it's probably just the -SINGLE option now that might just have this problem, not the default two stage downloader which does wait for a checksum/acknowledgment after each block transferred and if you miss receiving it you get those timeout errors.
Found another problem in loadp2 when running the two stage loader. It doesn't wait to drain the transmit buffer on Mac platforms after each block before it starts the timeout period for getting a response, it only compiles in the call to wait_drain() for win32 platforms. When I commented out the conditional #ifdef in this code so it would be included on my Mac it started working at lower baud rates like 28800 without a timeout error (not that you'd typically want to use that speed).
This is another loadp2 bug. @ersmith, did you want to fix that? Maybe it was meant to be #ifndef _WIN32 like the loadfile function had earlier in the file, but I think Windows platforms potentially would also benefit from this wait_drain call being implemented correctly (currently it just does a 30ms wait on Windows platforms).
Before the fix, the download will timeout:
$ loadp2 RBTest10.bin -t -l 28800
ERROR: timeout waiting for checksum at end: got -1
Fix in loadp2.c:
// receive checksum, verify it int recv_chksum = 0; //#ifdef _WIN32 wait_drain(); //#endif num = rx_timeout((uint8_t *)buffer, 3, 400); <---- a 400ms timeout might not be enough at low baud rates if the O/S has large serial transmit buffers and you are not calling wait_drain to wait until the O/S has flushed them out.After the fix the download works:
$ loadp2 RBTest10.bin -t -l 28800
( Entering terminal mode. Press Ctrl-] or Ctrl-Z to exit. )
clkfreq = 25000000, clkmode = $0
Test pins 0....V....1....V....2....V....3....V....4....V....5....V....6...
Init Hi 1111111111111111111111111111111111111111111111111111111111
Test Lo 0000000000000000000000000000000000000000000000000000000000
Init Lo 0000000000000000000000000000000000000000000000000000000000
Test Hi 1111111111111111111111111111111111111111111111111111111111
Done 0....V....1....V....2....V....3....V....4....V....5....V....6...
Passed shorts test
Also in loadp2.c if you initialize use_checksum to 1, it does seems to work on my Mac OS X at least, and fixes the -SINGLE option problem I mentioned earlier by waiting for the "." acknowledgment from the P2 loader before dropping into the terminal and changing the baud rate which potentially corrupts the ongoing data transmission if the loader baud rate is different to the terminal console baud rate.
So it should be possible to change this line
back to this:
@rogloh : I've updated the loadp2 git repository. I hope the version there now will fix your problems.
Thanks,
Eric
I've had occasional load issues just like this with my own custom boards too... Hope this fixes it.
It always works perfectly with Eval board though. Also, the Prop tool works perfectly with my own boards. Something strange there...
Thanks Eric. I'll update with your latest and retest. In the end I think had encountered about four total issues, and some needed to have different baud rates configured to be encountered. You can observe all these problems if you monitor the serial data lines with a logic analyzer or scope and see when it fails and compare with the expected data delays between transfers in the download sequence . Most of the issues seem to stem from the fact that on a PropPlug there is a USB FIFO holding characters sent to the P2 and that also needs to have time to drain, and the existing wait_drain() function we have is only waiting for the characters to leave the PC/Mac, but doesn't factor in the additional external FIFO drain time. A raw serial port delivering characters directly with no FIFO probably wouldn't have this drain time problem.
1) in -SINGLE mode, there was no waiting for any ack using the "." character from the Prop2 which meant it could continue on and change the baud rate prematurely to the console rate while the transfer was still in progress in the FIFO if the loader baud rate was low and different from the console rate. Enabling the "use_checksum" feature seemed to help this, however the timeout interval really needs to account for the additional USB FIFO drain time which varies with baud rate. Right now it was fixed at 100ms, but it could neeed to be as much as 5120/baud rate or 533ms down at 9600bps if someone used a really slow serial link transfer. I do think the timeouts should be computed based on the loader baud rate instead of being fixed.
2) in the regular two stage loader (CHIP) mode, there were 3 more issues:
a) with slow loader rates, the two first autobaud characters (0x55) can appear very early, immediately after the "~" char that ends the first stage download and this can cause an initial download timeout, even though you do retry and send them again up to 5 times. The first back to back autobaud characters after the ~ fail because the second stage loader code has not started in the COG at that time but I'm not yet quite sure why the repeated attempts also continue to fail but they can.
b) at slow loader rates there is a risk that the autobaud fails because the code doesn't first wait for the final 5th transition from 0 to 1 in the first autobaud character before trying to match the 0x55 in the next character and that last transition in the first byte corrupts the second byte matching (because of the start bit there are five 0->1 transitions in the autobaud character not four). As a workaround I added a small wait for two extra bit periods which seemed to help resolve this, as long as the second character it validates arrives later and not back to back when the loader rate is high, because then it doesn't give the autobaud function enough time to complete. It's somewhat tricky timing if the characters arrive back to back.
c) if the load rate is very slow, the 400ms checksum rx timeout per file portion downloaded is not still enough to account for the receive USB FIFO from emptying and the code can timeout.
Maybe for now we can assume a default 512 byte FIFO size (assuming a prop plug with FT231X) so the timeouts get computed based on this size and the loader baud rate, and then have an optional command line parameter to override this FIFO size in case people want to use other/future USB serial devices with larger FIFOs. Also if it does timeout with an error, loadp2 could then suggest to the user to increase the FIFO size parameter on the command line so people could have some control over what is happening there if needed.
Also I was able to get 3Mbps downloads working intermittently but the autobauding is very marginal at that speed with RCFAST. When autobauding works it can successfully download the remaining file at this speed on a Mac with FT231X in the Prop plug but it doesn't often succeed. There are not many P2 cycles available to measure the bit period at 24-25MHz the way it is done. If this check could be sped up it might be able to do 3Mbps more reliably. Maybe there is some way a smartpin mode can measure the bit period in hardware instead of timing it in software. Not sure. The -SINGLE option with 3Mbps is readily achievable but it sends 3x as much ASCII data as needed so it's still slower than what could be done with pure binary data at 3Mbps.
Do you use a Mac or PC? I first noticed this loadp2 timeout stuff when I used a PropPlug on a JonnyMac board. P2-EVAL worked fine but JonnyMac board had lots of timeout errors with an older loadp2 I had. Weird because both setups use the FT231X device. I wondered if it was due to small RCFAST differences somehow, if the rev B chips had different typical speeds vs rev C chips?
FWIR, the ROM loader using RCFAST does use smartpins to do the autobaud, and it measures over multiple baud-bits to get better precision.
Do you have other UARTs to try ? eg FT232H can do 24M/N, so 2.666667MBd is also valid.
Yeah fractional clocks would be handy, as there are only around 8 or 7 clocks at 3Mbps with 23-25MHz RCFAST and quantization error could be high.
I don't have other UARTs here no. I think Tubular probably has a good range of them including FT2232 etc.
Yeah I have a heap of different FTDI ones in different form factors, but haven't looked at many exar ones (as rec by jmg) as yet
There's a lot of FT2232H's left over from our work with P2 FPGAs, including converters to 'prop plug' 4 pin format
More recently I've been designing around the CP2102N despite the current supply issues
I connected a P2Eval and ran some quick Autobaud ping tests, using ROM+RCFAST, using PL2303GC as that's the finest baud part I have easily connected.
8MBd always fails,
4.8MBd seems the highest reliable autobaud choice.
Quite a few baud values 'mostly' work. A more gradual failure curve than I expected ?
I think the CP2102N supports 4000000 , 3428571, 3000000,... (24M/N)
A reliable 3Mbps option with loadp2 for prop plug would be nice, that seems to be the FT231X's upper limit anyway.
I do not have many boards to test loadp2 with, so I have to rely on bug fixes from the community. The best way to communicate these is to submit pull requests (or at least bug reports) to my loadp2 github repository.
Yeah I will try to do that once I test it a bit more. I want to know why your retry code is failing. It's very easy to make happen with the loader baud rate set to 115200bps in CHIP mode.
Just trying some faster loadp2 checks ( on a Dec 2019 build as I cannot build from source) and I notice -SINGLE has fewer checks and seems to give false positives - it can report file loaded, with no verify or checksum
The two step loader reports more info and seems to include a checksum verify step.
Yes, jmg that is an issue. The latest code Eric added has improved this and has put in the wait for the "." char to be sure the file is loaded in SINGLE mode.
By the way I've just improved the autobaud in loadp2 by sending $80 instead of $55 and measuring clock period for 8 serial bit times being logic low (this is including the start bit) and then shifting this value up by 13 bits so fractional baudrates with the smartpin WXPIN parameter should now work. It also now lets me do 3Mbps which was not reliable before. Still testing but when I'm done I'll submit these changes to Github via a PR or do a bug fix post for Eric.
The other delay changes I put in seem to let me now load from 14400bps up to 3Mbps in both -SINGLE and the default -CHIP modes and I'm not seeing timeouts (yet). Going even lower down to 9600bps and below seems to need another change in the port detection timeout area. I might look at that too. I know that these baud rates would be very uncommon but perhaps some setups might have very slow serial links or something and it could still be useful to support.