Shop OBEX P1 Docs P2 Docs Learn Events
P2 Silicon default boot issue. — Parallax Forums

P2 Silicon default boot issue.

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
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

  • cgraceycgracey Posts: 14,131
    That may be it. I saw that, too, but figured try_serial might have been needed. I will be reviewing this more tomorrow. That would be great if it was just a programming error. I don't know why it didn't show up on the FPGA as an obvious problem, though.
  • I found the P123-A7 build needed a P59 pull up to get going.
    The other boards were Ok with no resistors.

    What are the floating states of the silicon pins P59..P61?
  • cgraceycgracey Posts: 14,131
    ozpropdev wrote: »
    I found the P123-A7 build needed a P59 pull up to get going.
    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.
  • Chip
    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?
  • ozpropdev wrote: »
    Chip
    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).
  • cgraceycgracey Posts: 14,131
    edited 2018-10-16 01:41
    ozpropdev wrote: »
    Chip
    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?

    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.
  • evanhevanh Posts: 15,091
    edited 2018-10-25 05:04
    I'm expecting a fresh FPGA image. We'll be double checking each change.

    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.

  • cgraceycgracey Posts: 14,131
    Yes, after HDMI is proven, I'll make the images.
  • There is a sign bug in the I/Q modulator too.

  • evanhevanh Posts: 15,091
    potatohead wrote: »
    There is a sign bug in the I/Q modulator too.

    That'll be the one. Somewhere deep in the streamer. :)

  • Oh, there were two, that one, and the DAC data getting clobbered when streamer is in nibble or lower bit per pixel mode.

  • cgraceycgracey Posts: 14,131
    The sign bug only exists in the silicon, though, not the FPGA, and it was due to some Verilog language vagary. That's been recoded to ensure it works on both now. That bug affected the IQ modulator, the smart pin measurement modes which inc and dec, and the ALTx instructions where s[17:09] was signed.

    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.
  • That's a nice polish pass.

    :D

    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.

  • evanhevanh Posts: 15,091
    cgracey wrote: »
    The sign bug only exists in the silicon, though, not the FPGA, and it was due to some Verilog language vagary. That's been recoded to ensure it works on both now. That bug affected the IQ modulator, the smart pin measurement modes which inc and dec, and the ALTx instructions where s[17:09] was signed.

    I remember that now.

  • jmgjmg Posts: 15,140
    potatohead wrote: »
    That's a nice polish pass.

    :D

    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.

    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.
  • Was there not some LVDM stuff too?

    J
  • evanhevanh Posts: 15,091
    LVDS - only in support of HDMI. The embedded LCD interfaced, called LVDS, is not supported.

    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.

  • cgracey wrote: »
    The sign bug only exists in the silicon, though, not the FPGA, and it was due to some Verilog language vagary. That's been recoded to ensure it works on both now. That bug affected the IQ modulator, the smart pin measurement modes which inc and dec, and the ALTx instructions where s[17:09] was signed.

    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.

    Also:

    - XORO32 has new constants
    - BIT_DAC outputs $aa/$bb, not $ab/$00
  • cgraceycgracey Posts: 14,131
    Thanks for the reminder, TonyB_. I had forgotten about those two!
  • potatohead wrote: »
    That's a nice polish pass.

    :D

    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.

    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
  • jmgjmg Posts: 15,140
    Tubular wrote: »
    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.
  • cgraceycgracey Posts: 14,131
    jmg wrote: »
    Tubular wrote: »
    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.
  • Cluso99Cluso99 Posts: 18,066
    edited 2018-10-26 08:16
    Just a thought...
    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.
Sign In or Register to comment.