JMG,
Everyone is scratching heads. There wasn't anything intentionally changed.
Yes, I was unclear what ozpropdev changed in the test tho. One way to read it was an older PNut works with newest FPGA image ?
Or, does it mean a PNut what works with v23 image, now fails on v24 image ?
Here's where i'm at:
FPGA= V23a image, Pnut V23 and Pnut V24 work Ok.
FPGA = V24 image, Both V23 and V24 fail to load but both versions ID(Ctrl-G) Prop2 Ok. Dave's LOADP2 works though?
Tried 3 different PC's and multiple cables with no change.
... I've been bothered by PNut's comms stability since I got my Prop123 board. Ie: I can't use PNut for my Prop123-A9 board. The data flow is precise and complete but the handshaking is wacky.
In particular, the Prop gets a physical reset pulse just when the main binary transmit starts.
From memory, it's the third of three resets that occur during the whole process after pressing F11.
Too many resets, and especially a very late one could cause problems. Just one clean reset should be all that's needed ?
Do the FPGAs have identical OSC and PLL settings ?
I could imagine a different PLL choice locks in a different time, and if the PLL is not stable when RX starts, that could throw things.
The ONLY thing that changed was that hub timing was sped up to match the number of cogs, instead of a static 1:16, as before.
It's also only one variant of FPGA, so it's likely something is slightly different on that board, so becomes marginal for PNut only.
Faster HUB timing would move things, but not by much in comms-terms one would think.
Can you clean up the 3? reset pulses from PNut to have one reset, with a reasonable set-up time ?
Chip
I just noticed something.
The beMicro-A9 board used to identify its version as "Prop_Ver Au" the same as the P123-A9 board.
Now it shows as "Prop_Ver Fu".
Not sure when that changed or if that's relevant?
I also have my own loader which loads code Ok to the V24 in the board.
Scratching head.....
JMG,
It's an unintentional three RTS pulses (we thought it was DTR at the time) that shows up when in Wine specifically, Peter reported it didn't occur in his tests on VM'd WinXP. I'm presuming, like me, he doesn't have any dedicated Windoze setup. I have an old Win98 laptop but PNut doesn't work on that at all.
It appears as only two resets to the Prop, since the first two pulses are close enough that the first reset hasn't finished so is just extended instead.
The question on my mind right now is maybe Oz is getting some variation of the late (third) RTS occurring.
Chip
Hooray!
I managed to get the BeMicroA9 board working with Pnut by simply moving the PropPlug away from the board.
Works first time every time now.
Weird that the same PropPlug has been mated to this board for as long as their been images for this board.
Chip
Hooray!
I managed to get the BeMicroA9 board working with Pnut by simply moving the PropPlug away from the board.
Works first time every time now.
Weird that the same PropPlug has been mated to this board for as long as their been images for this board.
Strange. I wonder if a scope can catch the difference ?
Still sounds like something is marginal, but may not be the FPGA image itself.
...
I managed to get the BeMicroA9 board working with Pnut by simply moving the PropPlug away from the board.
How much 'move away' is needed ?
Reminds me of the thread around FLiP with GPS modules, but there the RF cross talk effect has a more direct understanding.
Here, the ground inductance and coupling will change, but surely by very small amounts.
Do you have other USB-UART Bridges you can try ?
V24a works fine with PropPlug back on board.
Phew!
Ok, but that still doesn't make sense, unless D[8] of CLKSET was '1' and a reset was occurring. That shouldn't have been the case, though. I wonder what the problem could have been.
I posted a new version 24a at the top of this thread. No need to get it if you already grabbed (and needed) the BeMicro v24a image I posted just above.
I used to see something similar with P2-Hot on the Nano, but in reverse. In that case, inserting a ~4" extension cable *wouldn't* work with a prop plug, but omitting it did.
I also ended up putting 30kohm pullups on all 3 pins - RX TX and RESn, which seemed to help a bit.
I used to see something similar with P2-Hot on the Nano, but in reverse. In that case, inserting a ~4" extension cable *wouldn't* work with a prop plug, but omitting it did.
I also ended up putting 30kohm pullups on all 3 pins - RX TX and RESn, which seemed to help a bit.
Yes. Pull-ups can overcome induced spikes. Even 1k ohm would be okay. Also, a cap to GND on RESn might help.
This recent conversation caused me to read over the BOOT PROCESS section of the documents. I have a few questions:
With the fuses "removed", will the boot ROM still go through the SHA-256/HMAC steps?
If the boot sequence boots from EEPROM first, how do you boot from serial once the EEPROM is programmed?
Is it correct that in order to program the EEPROM, the programming tool would first bootstrap the necessary code to then take subsequent commands to perform the actual programming?
It's just a recompile with the soft reset at D[25] for CLKSET.
I don't see CLKSET it the google doc. What is D's encoding for that instruction?
It's in the spreadsheet.
I'm thinking CLKSET needs to be renamed to HUBCFG, since it's used to seed the PRNG, set the digital pin filters, and set the clock mode. It has not been fully documented, yet.
Ozpropdev, could you please try the BeMicro_A9_Prop2_v24.jic again, but with a 0.1uF cap between ground and RESn? This problem is really bugging me. We need to know why this is happening.
Comments
I'm unclear - was this a FPGA image change, or a pnut.exe version change ?
ie is this indicating a FPGA, or PC side, issue ?
Everyone is scratching heads. There wasn't anything intentionally changed.
I think Chip is asking if there is passive pull-up resistors on or added to the BeMicro board.
Yes, I was unclear what ozpropdev changed in the test tho. One way to read it was an older PNut works with newest FPGA image ?
Or, does it mean a PNut what works with v23 image, now fails on v24 image ?
FPGA= V23a image, Pnut V23 and Pnut V24 work Ok.
FPGA = V24 image, Both V23 and V24 fail to load but both versions ID(Ctrl-G) Prop2 Ok. Dave's LOADP2 works though?
Tried 3 different PC's and multiple cables with no change.
Note: This only applies to the BeMicro-A9 image.
Too many resets, and especially a very late one could cause problems. Just one clean reset should be all that's needed ?
Do the FPGAs have identical OSC and PLL settings ?
I could imagine a different PLL choice locks in a different time, and if the PLL is not stable when RX starts, that could throw things.
What is the reset.release-to-serial setup time on LOADP2 vs PNut ?
The ONLY thing that changed was that hub timing was sped up to match the number of cogs, instead of a static 1:16, as before.
It's also only one variant of FPGA, so it's likely something is slightly different on that board, so becomes marginal for PNut only.
Faster HUB timing would move things, but not by much in comms-terms one would think.
Can you clean up the 3? reset pulses from PNut to have one reset, with a reasonable set-up time ?
I just noticed something.
The beMicro-A9 board used to identify its version as "Prop_Ver Au" the same as the P123-A9 board.
Now it shows as "Prop_Ver Fu".
Not sure when that changed or if that's relevant?
I also have my own loader which loads code Ok to the V24 in the board.
Scratching head.....
It's an unintentional three RTS pulses (we thought it was DTR at the time) that shows up when in Wine specifically, Peter reported it didn't occur in his tests on VM'd WinXP. I'm presuming, like me, he doesn't have any dedicated Windoze setup. I have an old Win98 laptop but PNut doesn't work on that at all.
It appears as only two resets to the Prop, since the first two pulses are close enough that the first reset hasn't finished so is just extended instead.
The question on my mind right now is maybe Oz is getting some variation of the late (third) RTS occurring.
Hooray!
I managed to get the BeMicroA9 board working with Pnut by simply moving the PropPlug away from the board.
Works first time every time now.
Weird that the same PropPlug has been mated to this board for as long as their been images for this board.
Strange. I wonder if a scope can catch the difference ?
Still sounds like something is marginal, but may not be the FPGA image itself.
How much 'move away' is needed ?
Reminds me of the thread around FLiP with GPS modules, but there the RF cross talk effect has a more direct understanding.
Here, the ground inductance and coupling will change, but surely by very small amounts.
Do you have other USB-UART Bridges you can try ?
Please try this version. It's just a recompile with the soft reset at D[25] for CLKSET. This change certainly jumbled things up from the last compile:
https://drive.google.com/file/d/0B9NbgkdrupkHVUh2NmJRZXU3Wlk/view?usp=sharing
Thanks.
V24a works fine with PropPlug back on board.
Phew!
Ok, but that still doesn't make sense, unless D[8] of CLKSET was '1' and a reset was occurring. That shouldn't have been the case, though. I wonder what the problem could have been.
I also ended up putting 30kohm pullups on all 3 pins - RX TX and RESn, which seemed to help a bit.
Yes. Pull-ups can overcome induced spikes. Even 1k ohm would be okay. Also, a cap to GND on RESn might help.
I don't see CLKSET it the google doc. What is D's encoding for that instruction?
It's in the spreadsheet.
I'm thinking CLKSET needs to be renamed to HUBCFG, since it's used to seed the PRNG, set the digital pin filters, and set the clock mode. It has not been fully documented, yet.