Reset issues on DE0-Nano/DE2-115
ozpropdev
Posts: 2,792
Hi P1 FPGA hackers!
I have successfully loaded my little Nano FPGA with the P1 core. Works great!
Loading my propeller program works only once from the Prop Tool.
Any attempt to load code after the first load fails. Even F7 Identify hardware fails.
A reboot in software doesn't help. Even tried toggling DTR from PST with no effect.
Only way to fix the problem is to power cycle the nano and all is good again.
After a power cycle F7 works as many times as you like. Even toggling DTR from PST works.
As soon as I load ram from prop tool , reset becomes inactive after that.
Rich was having the same issue I see.
Apart from this it works great!
Thanks Chip!
Any ideas?
Cheers
Brian
I have successfully loaded my little Nano FPGA with the P1 core. Works great!
Loading my propeller program works only once from the Prop Tool.
Any attempt to load code after the first load fails. Even F7 Identify hardware fails.
A reboot in software doesn't help. Even tried toggling DTR from PST with no effect.
Only way to fix the problem is to power cycle the nano and all is good again.
After a power cycle F7 works as many times as you like. Even toggling DTR from PST works.
As soon as I load ram from prop tool , reset becomes inactive after that.
Rich was having the same issue I see.
Apart from this it works great!
Thanks Chip!Any ideas?
Cheers
Brian
Comments
The issue seems to be related to P30 TX and the prop plug.
Using the DEMO spin code - FullDuplexSerial_test2.spin the fault can be replicated.
If the above configuration is used prop tool will fail on "Load RAM" after the first use.
Changing the TX pin to 20 instead of 30 for example fixes the reset problem.
I will attach an EEPROM later tonight and see if this is boot loader related.
@mindrobots
Rick,I see you have a eeprom fitted now. Can you try the above spin code.
Cheers
Brian
I went to run your program and now, I'm seeing strange things. I probably was seeing this yesterday since I did mention reset issues in a previous posting but thought it was just not having an EEPROM.
I went into Propeller Tool do do an F7 on the running Nano and:
Propeller Tool took forever to start up - to the point of Windows labeling it as "Not Responding". When it did finally start, F7 would cause a reset and then tell me my Prop wasn't there. But it did successfully reset back into PropForth which it read from the EEPROM. F7 would not ID the chip and kept resetting. I need to find a Prop board in my collection that uses a PropPlug to test that behavior on a real Prop - I don't recall it acting like that.
The forever startup is frustrating - I need to test that. I also need to reboot my laptop, it's been a while and it is Windows, after all.
I'll certainly be doing more testing with this!
As to your issue, I'm able to duplicate it also. (Quite accidentally this time)
I went into Propeller Tool with a freshly powered up and F7'd Nano and loaded the PST demo. It worked but I realized I had the crystal setting wrong from previous testing. I changed the code, saved it and hit F10 and Propeller Tool told me there was no prop there. F7 says there is no Prop there.
Power off Nano - Prop Tool goes into "Not Responding" (This may be a local PC issue)
Wait for Prop Tool to get back to normal
Power ON Nano -
F7 finds a Prop
F10 loads PST demo without problems and demo works
F7 - NO PROP FOUND
F10 - NO PROP FOUND
I'm guessing my Nano w/ EEPROM shows similar results except that it does appear to boot back into the EEPROM code. As it sits, I have no way to reprogram it since it is no longer recognized by the Propeller Tool once it resets into PropForth on the EEPROM - This is NOT NORMAL, I reload/reprogram PropForth onto a running Prop all the time.
Now, I'm off to reboot, have some breakfast and find a Prop board without USB so I can do some side by side testing.
That sounds exactly what I am seeing here. Hmmm...
I'm soldering up a test board now to try a few more ideas.
Cheers
Brian
It does cause a reset and the FPGA does respond and turns into a running Propeller that even loads code from EEPROM (we've proven that). It just can't handle responding to the F7 or an F10 in a timely manner.
I was about to try it on my DE2 but it's currently setup doing P2 development stuff.
I'll run some more tests on the De0-Nano and see what I find.
Cheers
Brian
Now with that little problem behind us:
1) Cycle power on your Nano
2) Start Propeller Toool
3) F7 will find the Prop and display the signature
4) F10 to load a program (I think it can be any program, I've seen it with PropForth and also with the PST demo
5) That program should work fine (as long as there isn't a reset since it is in RAM, DOH!)
6) F7 will say no Propeller is connected (I need to check this with a real Propeller but I think F7 ALWAYS responds)
7) F10 will fail with "no propeller found"
8) recycle power on the Nano
9) F7 will work
10) F10 will work but it puts you back to step #6
11) you never get here because you are in a loop between step #6 and step #10!!
This is with a bare Nano - NO EEPROM
If you have an EEPROM, the reset works and the fP1 (I kind of like that designation, whoever came up with it) loads from EEPROM and runs the program in EEPROM without issue. Reset does not corrupt the FPGA Propeller in any way.
This makes me think it could be timing with the reset AFTER the initial power on versus the reset after a program has been loaded. Something the reset and the loader process have in common or something the loader trigger that then causes both to fail.
F7 by itself can be done forever. Once you do an F10, you have corrupted it causing the need for a power cycle.
EDIT1: DOH! Of course it does!! (Does F7 from the Prop Tool cause a reset? I guess I never paid attention before if it reset my program or not.)
Propeller Tool and BST work the same so I assume it isn't an IDE issue in any way.
Time to see what F7 does with a real Propeller......
EDIT2: Real Propeller results
Real Prop: With one program in EEPROM (PropForth in this case) and a different program loaded to RAM (PST Demo) , the RAM program runs until you F7 and then the Propeller responds to the F7 and then loads the program from EEPROM.
fProp (NanoProp): With one program in EEPROM (PropForth in this case) and a different program loaded to RAM (PST Demo) , the RAM program runs until you F7 and the Propeller DOES NOT respond to the F7 but it DOES load the program from EEPROM and it runs successfully.
This behavior is annoying when you are using F10 (power cycling isn't too difficult) but it makes the fP1 unprogrammable after the first F11 if you put an EEPROM on it. :frown:
The Eeprom was programmed by a real prop1 and verified Ok.
Eeprom boots Ok on DE0-Nano and code runs fine.
Any form of reset(F7 in Prop Tool,PST DTR toggle or REBOOT in spin) never resets correctly.
Power cycle is needed every time to reset.
I'll keep digging....
Cheers
Brian
Edit: patching this will not be trivial...
Edit 2: the demo doesn't start, it was my mistake. I will search for the bug tomorrow, unless someone else find it earlier
Forget this: I don't think so, the code in RAM does not start working - if you don't have EEPROM, nothing appears to happen. If you have EEPROM, it resets and loads from EEPROM.
I'll have to try it with a pair of blinky programs instead of two serial I/O related programs to prove this theory one way or the other.
EDIT: New Experimenting with blinky LEDs on the Nano
Fast LED blinker in EEPROM
Slow LED blinker in Propeller Tool
F10 - loads and runs slow blinker
F7 - Prop returns a response, resets and runs the Fast blinker from EEPROM
F10 - loads and runs slow blinker
F7 - same as above....
Remove EEPROM
F10 - loads slow blinker and runs
F7 - Prop returns a response, and does nothing (RAM cleared so there is nothing to run?)
F10 - loads slow blinker and runs
F7 - same as above
So, now what do we know??
I'm not sure, I'm confused.
@pik33, I think you are on to something with:
but in my tests, it was the EEPROM program that was loaded and interfering EXCEPT I don't think the program had enough time to load to start sending characters out yet so I'm not sure what was interfering.
Did you see in the verilog where it doesn't reset RAM?
I think this sounds like a 'clean slate' issue - a FPGA reprogram puts the FPGA back into a known start state
(should be the same as a Board Power cycle), so it sounds like the Prop Reset does not quite have the 'coverage or reach' it should have ?
Put a second prop plug onto the Nano and ran the FullDuplexSerial_test2.spin demo on pins 4 & 6. Runs Ok.
Code can be loaded using "Load RAM" as many times as you like, no problems.
F7 - Identify Hardware works every time. No problems.
Problem seems to be linked to P30 being used as TX by code?
Good work. I'll have to try it out.
Now you mention it, I think I may have seen notes on that.
In that case, the issue is the PC end has a flood of data coming into the port, while it is getting the house-keeping done.
You could check that with a break-switch, in the TX line, to confirm it really is the food-effect.
Maybe try different download tool chains ?
I'd say the PC Sw needs to flush the RX buffer after issuing a reset, and not take too long between Port open, and reset issue, to avoid over run effects. If the Baud rate effects this, it would suggest the byte-count matters.
If I load the EEPROM with the standard P30,P31 configuration it fails to reboot after a reset.
If I change just the Tx to another pin and reload the EEPROM it boots every time after reset.
In my own code in EEPROM, comms sits dormant until called for.
Code boots from EEPROM fine, but if a reset is done via any of the above mentioned methods
it wont reboot again unless I power cycle the nano.
If the code in EEPROM uses P30 as Tx the only way I can reload the EEPROM with new code
is to use "Load EEPROM" almost straight away after a power cycle or programming will always fail.
I sometimes have to use a real P1 to program the EEPROM if its a large program and I'm not quick enough.
Brian
(1) It is enough to do a serial.start to make the Propeller undetectable
(2) The Propeler is undetectable because it doesn't respond (no activity on Tx)
Maybe I can hook my DE2 up running P2 code and capture the Tx/Rx data for a closer look.
Looks like I'm in for a big night of coffee drinking....
Then I commented this:
if_z or dira,txmask
The bug disappeared, the Propeller is detectable.
Then I restored original fullduplexserial code, only commented this line
Edit 3. E
if_z or dira,txmask
Demo is not working, but the Propeller is detectable.
Strange bug.
Edit: tried to run simple object which only does or dira, #000000_00000000_00000000_00000000. This doesn't cause the bug
Tried to do the same inside fullduplexserial: bug is active
Edit2: if fullduplexserial object is stopped immediately after start, there is no bug
Edit3. I am trying to simplyfy a "bug maker". Removed all code from fullduplexserial pasm, after this
or dira, txmask,
added infinite loop instead. Removed all demo code leaving only serial.start, wait, serial.stop. Bug is active. Next I will try to remove next part of code to locate what instruction/combination causes the problem. The goal is to make a minimal bug maker.
I
'FPGA Reset bug maker v. 1112 VAR long cog 'cog flag/id long rx_head '9 contiguous longs long rx_tail long tx_head long tx_tail long rx_pin long tx_pin long rxtx_mode long bit_ticks long buffer_ptr byte rx_buffer[16] 'transmit and receive buffers byte tx_buffer[16] PUB bug Start(31, 30, %0000, 9_600) 'requires 1 cog for operation Wait_1_Second stop PUB Wait_1_Second |i {{ Pauses the calling cog's execution for approximately one second. parameters: none return: none example usage: Wait_1_Second }} waitcnt(cnt + clkfreq) PUB start(rxpin, txpin, mode, baudrate) : okay '' Start serial driver - starts a cog '' returns false if no cog available '' '' mode bit 0 = invert rx '' mode bit 1 = invert tx '' mode bit 2 = open-drain/source tx '' mode bit 3 = ignore tx echo on rx stop longfill(@rx_head, 0, 4) longmove(@rx_pin, @rxpin, 3) bit_ticks := clkfreq / baudrate buffer_ptr := @rx_buffer okay := cog := cognew(@entry, @rx_head) + 1 PUB stop '' Stop serial driver - frees a cog if cog cogstop(cog~ - 1) longfill(@rx_head, 0, 9) DAT '*********************************** '* Assembly language serial driver * '*********************************** org ' ' ' Entry ' entry mov t1,par 'get structure address add t1,#4 << 2 'skip past heads and tails rdlong t2,t1 'get rx_pin mov rxmask,#1 shl rxmask,t2 add t1,#4 'get tx_pin rdlong t2,t1 mov txmask,#1 shl txmask,t2 add t1,#4 'get rxtx_mode rdlong rxtxmode,t1 add t1,#4 'get bit_ticks rdlong bitticks,t1 add t1,#4 'get buffer_ptr rdlong rxbuff,t1 mov txbuff,rxbuff add txbuff,#16 test rxtxmode,#%100 wz 'init tx pin according to mode test rxtxmode,#%010 wc if_z_ne_c or outa,txmask if_z or dira,txmask loop jmp #loop ' t1 res 1 t2 res 1 t3 res 1 rxtxmode res 1 bitticks res 1 rxmask res 1 rxbuff res 1 rxdata res 1 rxbits res 1 rxcnt res 1 rxcode res 1 txmask res 1 txbuff res 1 txdata res 1 txbits res 1 txcnt res 1 txcode res 1The PASM code will cause a reset problem
The SPIN code variant does not?
Huh?
'FPGA Reset test con _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 tx = 30 pub main cognew(@pasm,0) 'this will cause a reset problem 'dira[tx] := 1 'these spin instruction DONT cause the reset issue? 'outa[tx] := 1 repeat dat pasm or dira,_tx_pin or outa,_tx_pin me jmp #@me _tx_pin long |< txCheers
Brian
What if you use P30, and physically break the Tx line to the PC ?
Trying to nail if it is something the P30 does on the FPGA board, or the Data arriving at the PC that is the issue.
The pin state is held high after a reset blocking further comms.
Setting the pin low before a reset eliminates the reset issue.
I'm doing more tests to verify this now.
Brian
Heres the simple code I used to verify thr reset issue.
Calling "mycode" from Cog 0 works Ok.
Starting "mycode" in cogs1-7 blocks reset.
Setting pin state low (outa[30] :=0) fixes reset issue.
Cheers
Brian
C
In file cog.v about line 333 is :
always @(posedge clk_cog) if (setouta) outa <= alu_r; always @(posedge clk_cog) if (setdira) dira <= alu_r;and should be
always @(posedge clk_cog) if (setouta && nres) outa <= alu_r; else if (!nres) outa<=0; always @(posedge clk_cog) if (setdira && nres) dira <= alu_r; else if (!nres) dira<=0;The reset signal didn't reset outa and dira.
Please test if it works in your environment.
I only have Quartus II 13.0 web edition which does not allow me to open projects.
I tried downloading version 14.0 only to find its for 64bit machines. So I can't compile your patch.
The Altera webpage keeps bouncing me back to the same place.
Apparently there's a 32 bit version somewhere out there. I'll try again tomorrow.
Cheers
Brian
You can download 13.1:
http://dl.altera.com/13.1/?edition=web
There is 32 bit 13.1, and no 14.0
or you can simply start a new project in 13.0, show it the directory where you have source files and use top.tdf as a main entity.
Set verilog version to SystemVerilog.
Then compile and run
.. or try this .sof (untested, I have no DE0-nano)
I havs a Nano running and a BeMicro CV, I was hoping to get my DE2 up and running this weekend with pik33's P1 Block.
I noticed a warning about a device wide reset
(ID: 13003)
#13003, which is explained here http://drlnet.dyndns.org/help/quartus/webhelp/mergedProjects/msgs/whnjs.htm
"CAUSE: You enabled the device-wide reset (DEV_CLRn) pin for the current design's target device. As a result, Analysis & Synthesis enabled the NOT Gate Push-Back on some registers in the current project. For devices that have the DEV_CLRn option, these registers will be set rather than reset when DEV_CLRn is enabled.
ACTION: No action is required. However, if you want the Quartus II software to be reset rather than set the registers with preset signals, turn off the NOT Gate Push-Back logic option for those registers."
I don't know if this has anything to do with this problem and won't have time to look at it until the baby goes to sleep:)
In other discussions, this setting is related to J-tag instability... so, it certainly sounds like it could be the villain.
Rich
I have had a DE0_Nano since January 1013,
@Rick Verilog is much more fun than Forth.
Ron