Chip
All FPGA images loaded Ok except DE0-Nano bare.
Tried 2 Nano's ,both failed (No hardware found from Pnut) on bare image but Ok with add-on image.
My existing code is broken until I can update the new changes to edge events and interrupts.
Looking forward to the new docs.
Chip
All FPGA images loaded Ok except DE0-Nano bare.
Tried 2 Nano's ,both failed (No hardware found from Pnut) on bare image but Ok with add-on image.
My existing code is broken until I can update the new changes to edge events and interrupts.
Looking forward to the new docs.
Edit: Changes applied, P123 & DE2 running nicely!
I tested the DE0-Nano bare compile and it worked. I must have done something wrong in copying the file. I'll fix it. Thanks.
I'm not sure I understand how the booter in this release works...
Does PNUT somehow bypass what would be the normal boot process?
I see the code looks for a pullup resistor on SPI CS and if it finds it boots from flash.
How would you interrupt this to reprogram the flash?
Do you need a jumper to remove pullup?
I'm not sure I understand how the booter in this release works...
Does PNUT somehow bypass what would be the normal boot process?
I see the code looks for a pullup resistor on SPI CS and if it finds it boots from flash.
How would you interrupt this to reprogram the flash?
Do you need a jumper to remove pullup?
You would have to remove the SPI_CK pull-up (assuming there's also an SPI_CS pull-up AND the SPI image has a proper HMAC signature) and then serially load some code to reprogram the SPI flash.
The only way the host system doesn't have a chance to load serially is when these three conditions are met:
1) There is a pull-up on SPI_CS.
2) There is a properly-signed image in flash from addresses $0 to $3FF.
3) There is a pull-up on SPI_CK.
The only way to get an image into flash is to serially load a program which puts one there.
Chip
I'm still having issues with the Nano Bare image (v11a).
Pnut V11a still cant detect the Prop2 with a Ctrl-G but I can get a response from the booter via my own code.
Prop_Ver Cu
Nano appears to be alive?
Edit: BTW P123-A7 running Ok. (Tested with Spinning Fozzie + other assorted code)
Chip
I'm still having issues with the Nano Bare image (v11a).
Pnut V11a still cant detect the Prop2 with a Ctrl-G but I can get a response from the booter via my own code.
Prop_Ver Cu
Nano appears to be alive?
Edit: BTW P123-A7 running Ok. (Tested with Spinning Fozzie + other assorted code)
That's strange. Mine was programmed from the latest file and it works fine, in all ways. It sounds like you are not getting a reset signal out of your PropPlug, though the serial is working. Is there any way you can check that?
Chip
I managed to load and run a program into the Bare Nano using "Prop_Hex" Ok.
It appears that Pnut is not playing nicely with the bare nano.
Weird that it works with nanos with add on boards and all the other FPGA's.
Chip
I managed to load and run a program into the Bare Nano using "Prop_Hex" Ok.
It appears that Pnut is not playing nicely with the bare nano.
Weird that it works with nanos with add on boards and all the other FPGA's.
Maybe there is some kind of timing problem, but why only on that board?
Chip
I've tried 2 different PC's with this same result.
Pnut Gtrl-G returns "No hardware ..."
I then load my code into my bare nano using "Prop_Hex" and code rins Ok.
I then go back to Pnut and try another Ctrl-G or a F11 it works once.
If I attempt any further Ctrl-G's or F11's it fails.
BTW I have to put a clkset #$ff at the start of my code to get it to work if I load it with Prop_Hex.
Hmm my DE0 is now running, with exactly the same setup as before (same DE0, same cables, prop plug, into same usb ports on same laptop). Whats more its working very reliably and now I can't get it to fail.
In between now and before I loaded the DE0 image for breakout pcb (which worked fine), then back to the bare image.
One thing I noticed is that if I pull the power, while the prop plug is still connected via usb to the laptop, reapplying the power causes multiple reboots about a second apart, before things settle down. I suspect thats more related to ftdi parasitics than anything else, but mention it in case
Ok this gets weirder.
Control-G in PNUT_11A is rock solid reliable now. Yesterday I couldn't get that response at all.
So I've been trying the serial loader. I couldn't get that to work initially (cut-paste Chip's string),
However " Prop_Chk 0 0 0 0"<CR> always responds "Prop_ver Cu"
Pasting the string (control-v) directly into Realterm/TeraTerm/PST, followed by manually pressing Enter doesn't work. Edit: Teraterm works
However using RealTerms 'send ascii' works and responds "PASS" just fine.
So not sure what to make of it all. When its solid, its really solid.
What terminal program are you guys using? I'm testing at 115200 baud, what about you?
I think I see the problem. I didn't have the weak pull-up enabled on the RESn pin. The DE0-Nano add-on board has a pull-up resistor on it, but the bare doesn't, of course. This is an FPGA configuration matter. I'm going to recompile.
That sounds like the sort of thing that could explain it.
I can't get it to fall over now, despite reprogramming the altera chip and trying various orders of prop plug attachment.
Looks like the Prop_Hex issue I encountered is more to do with control-v being interpreted as a single command keystroke to be sent via the terminal, rather than pasting the Prop_Hex string and terminator. If I use the Alt-V in Teraterm, or the ASCII string sender in Realterm, everything works fine. The Enter at the end isn't required, just the tilde.
However I couldn't get PST to work pasting the string.
That sounds like the sort of thing that could explain it.
I can't get it to fall over now, despite reprogramming the altera chip and trying various orders of prop plug attachment.
Looks like the Prop_Hex issue I encountered is more to do with control-v being interpreted as a single command keystroke to be sent via the terminal, rather than pasting the Prop_Hex string and terminator. If I use the Alt-V in Teraterm, or the ASCII string sender in Realterm, everything works fine. The Enter at the end isn't required, just the tilde.
However I couldn't get PST to work pasting the string.
I just updated the .zip file at the top of the thread. I added a weak pull-up on RESn for the DE0-Nano-Bare FPGA image. That should fix the problem.
Regarding, the Parallax Serial Terminal: Yes, paste is broken right now. Jeff knows about this and is going to fix it.
My P123 board seems to work like before after the update.
Took me a moment to figure out Prop_Chk 0 0 0 0...
Had to read instructions to remember that you have to put in a leading space.
Had to set baud to 115200
I'm also seeing that paste in PST doesn't work right.
Does PNut now use this text serial mode to load code?
Seems to load just as fast as before...
Comments
Yes. It can save an instruction if you start out with a negative number.
All FPGA images loaded Ok except DE0-Nano bare.
Tried 2 Nano's ,both failed (No hardware found from Pnut) on bare image but Ok with add-on image.
My existing code is broken until I can update the new changes to edge events and interrupts.
Looking forward to the new docs.
Edit: Changes applied, P123 & DE2 running nicely!
I tested the DE0-Nano bare compile and it worked. I must have done something wrong in copying the file. I'll fix it. Thanks.
The DE0 with breakout board responds fine
Does PNUT somehow bypass what would be the normal boot process?
I see the code looks for a pullup resistor on SPI CS and if it finds it boots from flash.
How would you interrupt this to reprogram the flash?
Do you need a jumper to remove pullup?
You would have to remove the SPI_CK pull-up (assuming there's also an SPI_CS pull-up AND the SPI image has a proper HMAC signature) and then serially load some code to reprogram the SPI flash.
The only way the host system doesn't have a chance to load serially is when these three conditions are met:
1) There is a pull-up on SPI_CS.
2) There is a properly-signed image in flash from addresses $0 to $3FF.
3) There is a pull-up on SPI_CK.
The only way to get an image into flash is to serially load a program which puts one there.
Then, it will boot serially on reset...
There is a new DE0_Nano_Bare_Prop2_V11a.jic file which works.
There is a new Prop123_A7_Prop2_v11.rbf file for some Prop123-A7 boards which Tubular has added the PLL resistor to.
There is a new PNut_v11a.exe file which supports the Prop123-A7 boards that Tubular fixed.
Have any of you guys had a conversation via a terminal with the serial loader, yet?
I'm still having issues with the Nano Bare image (v11a).
Pnut V11a still cant detect the Prop2 with a Ctrl-G but I can get a response from the booter via my own code. Nano appears to be alive?
Edit: BTW P123-A7 running Ok. (Tested with Spinning Fozzie + other assorted code)
That's strange. Mine was programmed from the latest file and it works fine, in all ways. It sounds like you are not getting a reset signal out of your PropPlug, though the serial is working. Is there any way you can check that?
Good news about the -A7 boards.
If you send this string to the serial loader, does it say "PASS" or "FAIL"?
“ Prop_Hex 0 0 0 0 FB F7 23 F6 FD FB 23 F6 25 26 80 FF 28 80 66 FD F0 FF 9F FD ~”
Can you run the regular DE0-Nano with the add on board?
I managed to load and run a program into the Bare Nano using "Prop_Hex" Ok.
It appears that Pnut is not playing nicely with the bare nano.
Weird that it works with nanos with add on boards and all the other FPGA's.
Maybe there is some kind of timing problem, but why only on that board?
But you reprogrammed it with the non-bare .jic file, right?
The regular non-bare version works Ok. It's only the bare version that pnut can't see.
I have no idea what the difference might be. My board is working, so I don't get the error.
I've tried 2 different PC's with this same result.
Pnut Gtrl-G returns "No hardware ..."
I then load my code into my bare nano using "Prop_Hex" and code rins Ok.
I then go back to Pnut and try another Ctrl-G or a F11 it works once.
If I attempt any further Ctrl-G's or F11's it fails.
BTW I have to put a clkset #$ff at the start of my code to get it to work if I load it with Prop_Hex.
Maybe it's clock switchover related?
In between now and before I loaded the DE0 image for breakout pcb (which worked fine), then back to the bare image.
One thing I noticed is that if I pull the power, while the prop plug is still connected via usb to the laptop, reapplying the power causes multiple reboots about a second apart, before things settle down. I suspect thats more related to ftdi parasitics than anything else, but mention it in case
I'll dig a bit deeper
Applying pull downs to these pins has no effect on INB. I have swapped PC's,cables,propplugs and nano's.
Randomly (~1 in 20) Ctrl-G and/or F11 work.
Control-G in PNUT_11A is rock solid reliable now. Yesterday I couldn't get that response at all.
So I've been trying the serial loader. I couldn't get that to work initially (cut-paste Chip's string),
However " Prop_Chk 0 0 0 0"<CR> always responds "Prop_ver Cu"
Pasting the string (control-v) directly into Realterm/TeraTerm/PST, followed by manually pressing Enter doesn't work. Edit: Teraterm works
However using RealTerms 'send ascii' works and responds "PASS" just fine.
So not sure what to make of it all. When its solid, its really solid.
What terminal program are you guys using? I'm testing at 115200 baud, what about you?
I can't get it to fall over now, despite reprogramming the altera chip and trying various orders of prop plug attachment.
Looks like the Prop_Hex issue I encountered is more to do with control-v being interpreted as a single command keystroke to be sent via the terminal, rather than pasting the Prop_Hex string and terminator. If I use the Alt-V in Teraterm, or the ASCII string sender in Realterm, everything works fine. The Enter at the end isn't required, just the tilde.
However I couldn't get PST to work pasting the string.
I just updated the .zip file at the top of the thread. I added a weak pull-up on RESn for the DE0-Nano-Bare FPGA image. That should fix the problem.
Regarding, the Parallax Serial Terminal: Yes, paste is broken right now. Jeff knows about this and is going to fix it.
Took me a moment to figure out Prop_Chk 0 0 0 0...
Had to read instructions to remember that you have to put in a leading space.
Had to set baud to 115200
I'm also seeing that paste in PST doesn't work right.
Does PNut now use this text serial mode to load code?
Seems to load just as fast as before...