P2 Silicon default boot issue.
ozpropdev
Posts: 2,792
in Propeller 2
Hi Chip
I've been looking into the P2 boot sequence and I believe I've found the reason for the unexpected P59 pull up scenario.
From the docs the default boot mode is shown as
The jump to 'try_serial' should be jump to 'reset_serial'.
Here's the relevant boot code for reference.
I've been looking into the P2 boot sequence and I believe I've found the reason for the unexpected P59 pull up scenario.
From the docs the default boot mode is shown as
Boot Pattern Set By Resistors P61 P60 P59 ===================================================== Serial window of 60s, default. none none none =====================================================Assuming 'none' means NOT pulled up then boot never makes it to serial mode.
The jump to 'try_serial' should be jump to 'reset_serial'.
Here's the relevant boot code for reference.
' If pull-up on spi_di then try serial ' callpa #spi_di,#check_pullup if_c jmp #reset_serial ' ' ' If pull-up on spi_cs then try to load from SPI memory ' callpa #spi_cs,#check_pullup if_c jmp #try_spi ' ' ' If pull-up on spi_ck (also sd_cs) then try to load from SD card ' callpa #spi_ck,#check_pullup if_c jmp #@_start_sdcard ' ' ' If no pull-down on spi_di then try serial ' '*** if we get here P59,P60 and P61 are low jmp #try_serial '**** should be reset_serial ***** ' Try serial if no pull-down on spi_di ' else, run SPI program if valid or float SPI pins and shut down ' try_serial testb flags,#spi_ok wz 'SPI program? if_nz fltl #spi_cs 'if no SPI program, float SPI pins if_nz fltl #spi_ck if_z setq #$FF 'if SPI program, move it into cog $000..$0FF if_z rdlong 0,#0 drvh #spi_di 'check pull-down on spi_di, leave floating callpa #spi_di,#check_pulldn 'c=0 if pull-down if_nc jmp #serial_done 'if pull-down on spi_di, boot if SPI okay (z=1) or shut down jmp #reset_serial 'else try serial ' ' ' Serial done ' on entry, z=1 if SPI program ' serial_done call #reset_pins 'reset pins if_z jmp #0 'if SPI program, run it, else shut down shut_down cogid x 'get cogid (in case jumped to from outside) hubset #1 'set 20KHz oscillator cogstop x 'shut down cog (floats pins) ' flags long 0
Comments
The other boards were Ok with no resistors.
What are the floating states of the silicon pins P59..P61?
They are very high-z.
A pull-up is checked for by pulsing the pin low for 1us, floating it for 5us, then checking for high.
Just confirming the pull-up issue.
Placing three pull-downs on a A7 board never boots to serial.
The cog #0 led flashes briefly and the P2V shuts down.
Do you intend on releasing a pre respin FPGA image?
Some logic has been changed: XORO32 (internally) and POP (writing Z).
That's right, Brian.
If there's a pull-down on P59, then this happens (from the Google doc in the FPGA files thread):
"SPI flash only (fast boot), no serial window.
If SPI flash fails then shutdown."
This is what was going on when we powered up the silicon. The pin was glitching negatively and without the 10pF of even a scope probe, it was winding up "low", as if a pull-down was present. So, it was immediately shutting down.
A couple of signed calculation bug fixes in the streamers.
R-jigging the OUT vs DIR timing to remove these tri-stating glitches.
Possible defaulting to clocked, at the pins, digital I/O for same reason. This could throw some existing serial timings out.
Peter seems to be sprucing up Taqoz some more.
Some minor instruction tweaks as Tony listed.
Config change for BIT_DAC mode to 2x 4-bit levels, although I guess this can't be tested by FPGA.
The new HDMI hardware in the streamers.
That'll be the one. Somewhere deep in the streamer.
In changes to improve the design:
- The POP instruction now sets Z to popped-value-equals-zero, not bit 30 of the popped value.
- The streamer modes now output proper DAC data for the 1/2/4-bit RFBYTE modes, in case the pins aren't enabled (e=0).
- HDMI is being added.
- Clock gating may be added to conserve dynamic power.
- ROM changes to accommodate pin glitches (in case they don't go away) for pull-up sensing.
- PeterJakacki and Cluso99 can improve their ROM code.
Rev B is going to be excellent. That said, I am anxious to get going on rev A. None of the current issues impact that activity.
I remember that now.
Yes, as Errata go, the errata list thus far, is not too bad....
Plenty can be done with RevA silicon, which is why I think Parallax may need more RevA P2 packaged once their board is ready to populate and propagate with the P2D2.
J
It would require quite a decent mode change for the serialiser, since this LVDS mode has the bit-depth all mixed up to pack it in tight.
Also:
- XORO32 has new constants
- BIT_DAC outputs $aa/$bb, not $ab/$00
Agreed.
There are a few things that have been discussed that I don' think Chip is going to act on, but add them here for completeness
- increasing the ADC current to potentially decrease noise
- being able to read onboard oscillators while operating from external osc/xtal
and
- being able to read external oscillator presence, while operating from internal osc
but I think all of those are custom-pad ring contained issues, are are not verilog-solvable, so yes, not rev B candidates.
That's right. Those things involve the pad ring and I'd rather not get into that on this pass.
Could the xtal parameters be saved in an internal register in parallel to writing to the pad ring?
If so, then a only a method/instruction to read that register back out would be needed.
You'd like to be able to read back whatever was last written via HUBSET. That could be done, but seems better handled in software, After all, if you think you can go alter it without some software agreement, so might somebody else.