...Whatever it is appears to lobotomize the USB smart pins, and when it's in this state, neither a code reload or hardware reset via the PB0 button on the Prop123-A9 board prior to reload works.
Sounds like maybe the reset coverage in the Verilog is not quite enough ? - as well as maybe some invalid state is being reached, to cause this in the first place ?
Does the smart pin mode reset on a P0 reset ?
FYI
A P2 reset does not initialize the LUT.
A reload of the FPGA from PX.exe or a power cycle will initialize the LUT.
It looks like LUT sharing could be it. The host<->driver command slots weren't getting reset at device disconnect or code startup. I'm still scratching my head a bit, though, as these locations are set as write events triggered by the "other" cog, so even if these locations were "dirty" when coming out of reset, they won't get written to until an eventID gets posted, which by then should be one that's legitimate. But I was able to reproduce the same type of issue that I had this morning that needed an FPGA image reload, but this time it worked after reset and code reload. I guess time will tell...
It looks like LUT sharing could be it. The host<->driver command slots weren't getting reset at device disconnect or code startup. I'm still scratching my head a bit, though, as these locations are set as write events triggered by the "other" cog, so even if these locations were "dirty" when coming out of reset, they won't get written to until an eventID gets posted, which by then should be one that's legitimate. But I was able to reproduce the same type of issue that I had this morning that needed an FPGA image reload, but this time it worked after reset and code reload. I guess time will tell...
Is this saying you have a software work-around, that is reliable in all situations, or does this still need a Verilog fix to avoid lock-out situations ?
Is this saying you have a software work-around, that is reliable in all situations, or does this still need a Verilog fix to avoid lock-out situations ?
I'm not 100% sure about anything, yet. The issue was fairly rare to begin with, and @ozpropdev's comment steered me to examine my LUT use, which did reveal a problem which *could* result in bad behavior that could survive a reset under certain circumstances. I've only had a single event occur since I made the change that *sometimes* in the past has required an FPGA image reload to get things working again, and this time just a reset and code reload cleared things up.
So for now, my thinking is that it is/was likely a programmer faux pas and not something that might require a Verilog fix.
Altogether I looked at over 20 values and didn't see a 101 pattern, which you would expect if the value was random. The value seen after power cycling the P123 board was variable.
Is this extra byte TX at start still an issue ?
Does it change at all with baud rate ?
(an earlier post mentioned two Baud formula ?)
What is the timing of the extra Char, relative to reset-exit ?
No.
BTW I have found testing with P1V images on A7 & A9 has shown some of the RGB led's are faulty anyway.
That's too bad. Is this a design flaw in the board? Is there any way to fix the RGB LED's? They are one thing that attracted me to the A9. Of course, they aren't the main reason I bought it but I certainly considered them a plus.
Ok, if it's not 100%, I can understand why it's not connected.
Was just thinking about stuff I could play around with in the GUI.
Still have several green LEDs and some buttons...
That's too bad. Is this a design flaw in the board? Is there any way to fix the RGB LED's?
No design flaw in the board just a heat damage issue for the RGB leds.
Noy surpising considering the large Cyclone V FPGA on the board.
I replaced my RGB leds's and verified their operation using a P1V image.
I added in some instructions which affect the OUT bit for a pin, while also setting or clearing the DIR bit. These instructions provide pipeline data forwarding for the OUTA/OUTB data, but not for the DIRA/DIRB data. So, one of these instructions should not be followed by an instruction which reads or writes the same DIRA/DIRB, as it will read old data. This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.
The first set (FLTx) clear the DIR bit to float the pin (and affect OUT), while the second set (DRVx) set the DIR bit to drive the pin (and affect OUT):
I'm almost done with the new PLL setup for the clock pins. After that, we are ready to make the chip. Still waiting for word from OnSemi, though, about the nature of their fuses.
The first set (FLTx) clear the DIR bit to float the pin (and affect OUT), while the second set (DRVx) set the DIR bit to drive the pin (and affect OUT):
Drive from float I think I can follow, as that has H/L and C/NC Z/NZ copies to the pin.
However, when you float a pin, there is only one action, ie the pin floats ?
What does the H/L and C/NC Z/NZ N/IN variants do here ?
I'm almost done with the new PLL setup for the clock pins. After that, we are ready to make the chip. Still waiting for word from OnSemi, though, about the nature of their fuses.
Cool. Did a post-VCO divider make it into the Verilog ?
So FLTL (for instance) clears DIR and sets OUT low? What would this be used for? Also, are the xxxIN variants setting OUT to the value of IN?
The FLTx instructions are a little weird, in that they bother to set the OUT bit to some state, while clearing the DIR bit, causing the pin to float. This is useful in cases where you want to float the pin, but set it up for output later, so that you don't need to buffer the next output state, just do a DIRH to drive it.
FLTIN and DRVIN clear and set the DIR bit, respectively, while sampling the IN bit state into C/NZ, as do all the other DIRx/OUTx/FLTx/DRVx instructions.
The first set (FLTx) clear the DIR bit to float the pin (and affect OUT), while the second set (DRVx) set the DIR bit to drive the pin (and affect OUT):
Drive from float I think I can follow, as that has H/L and C/NC Z/NZ copies to the pin.
However, when you float a pin, there is only one action, ie the pin floats ?
What does the H/L and C/NC Z/NZ N/IN variants do here ?
I'm almost done with the new PLL setup for the clock pins. After that, we are ready to make the chip. Still waiting for word from OnSemi, though, about the nature of their fuses.
Cool. Did a post-VCO divider make it into the Verilog ?
Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider. The only thing that I had to realize was that the change rate for the VCO bias voltage needed to be proportional to the speed of the divided XI/crystal. After understanding that, it was simple. Way simpler than I thought it would be.
... This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.
Hmm, pondering ... would combining the two functions (DIRx plus OUTx) into one register be okay? Eg:
Cog address $1FA is DIR[P0:P15];OUT[P0:P15]
Cog address $1FB is DIR[P16:P31];OUT[P16:P31]
Cog address $1FC is DIR[P32:P47];OUT[P32:P47]
Cog address $1FD is DIR[P48:P63];OUT[P48:P63]
I'm don't know if this limits the Streamer max data width but obviously software bit bashing will be 16-bit data width limited.
... This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.
Hmm, pondering ... would combining the two functions (DIRx plus OUTx) into one register be okay? Eg:
Cog address $1FA is DIR[P0:P15];OUT[P0:P15]
Cog address $1FB is DIR[P16:P31];OUT[P16:P31]
Cog address $1FC is DIR[P32:P47];OUT[P32:P47]
Cog address $1FD is DIR[P48:P63];OUT[P48:P63]
I'm don't know if this limits the Streamer max data width but obviously software bit bashing will be 16-bit data width limited.
As some tech support caller from GM Truck and Bus said to me 20 years ago, "That's a mighty, mighty SUCCULENT idea."
I need to think about the ramifications of doing that. It's no problem for the Streamer to handle that arrangement. I just don't know what it practically means for software. I worry it would cause more awkwardness than it would eliminate. It's very interesting, anyway.
... This is the price for having atomic pin-setting instructions which write both OUT and DIR registers.
Hmm, pondering ... would combining the two functions (DIRx plus OUTx) into one register be okay? Eg:
Cog address $1FA is DIR[P0:P15];OUT[P0:P15]
Cog address $1FB is DIR[P16:P31];OUT[P16:P31]
Cog address $1FC is DIR[P32:P47];OUT[P32:P47]
Cog address $1FD is DIR[P48:P63];OUT[P48:P63]
I'm don't know if this limits the Streamer max data width but obviously software bit bashing will be 16-bit data width limited.
The 16b width limit could be a problem, as there could be cases where users want/expect the full 32b BUS to Pin path.
(I often grumble about 32b MCU's having 16b timers, a 32b MCU with 16b ports is rather similar....)
Some MCUs handle the Float/Drive handling by having 4 port modes.
CMOS/OpenDrain/QuasiBiDir/Ip only
N-MOS open drain is done by OpenDrain mode and simple OUT drive, and P-MOS open drain can be managed by select of CMOS<->IP, with OUT=H
Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider...
Just thinking some more about SysCLK management across libraries, and from the other thread in handling HyperRAM, which has a 1us or 4us region tCMS.
To auto-manage that in a (eg) HyperRAM RAM-Disk driver, you could define a Crystal value at build time, then
can you then read-back the 6-bit, 10-bit, 4-bit values to extract the current SysCLK ?
Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider...
Just thinking some more about SysCLK management across libraries, and from the other thread in handling HyperRAM, which has a 1us or 4us region tCMS.
To auto-manage that in a (eg) HyperRAM RAM-Disk driver, you could define a Crystal value at build time, then
can you then read-back the 6-bit, 10-bit, 4-bit values to extract the current SysCLK ?
How do those 20 bits memory map ?
They go to a write-only register via the CLKSET instruction. On Prop1, we just copied those values to bottom RAM locations.
FLTIN and DRVIN clear and set the DIR bit, respectively, while sampling the IN bit state into C/NZ, as do all the other DIRx/OUTx/FLTx/DRVx instructions.
so IN is sampled BEFORE the change in DIR/OUT is applied?
FLTIN and DRVIN clear and set the DIR bit, respectively, while sampling the IN bit state into C/NZ, as do all the other DIRx/OUTx/FLTx/DRVx instructions.
so IN is sampled BEFORE the change in DIR/OUT is applied?
It can't be any other way, because it takes a few clocks for the pin states to reach INA/INB, then it takes a few clocks for OUT/DIR to reach the pins.
Just called Parallax Sales to order another P123 board. Unfortunately, they are sold out.
Not so happy with my options...
DE2-115 costs more, doesn't give as much and is way too big.
The BeMicro-A9 seems to have been out of stock for a year.
Are there any small A9 boards with reasonable cost?
Any plans to make more P123 boards?
Comments
Sounds like maybe the reset coverage in the Verilog is not quite enough ? - as well as maybe some invalid state is being reached, to cause this in the first place ?
Does the smart pin mode reset on a P0 reset ?
A P2 reset does not initialize the LUT.
A reload of the FPGA from PX.exe or a power cycle will initialize the LUT.
@ozpropdev to the rescue again :cool:
Is this saying you have a software work-around, that is reliable in all situations, or does this still need a Verilog fix to avoid lock-out situations ?
I'm not 100% sure about anything, yet. The issue was fairly rare to begin with, and @ozpropdev's comment steered me to examine my LUT use, which did reveal a problem which *could* result in bad behavior that could survive a reset under certain circumstances. I've only had a single event occur since I made the change that *sometimes* in the past has required an FPGA image reload to get things working again, and this time just a reset and code reload cleared things up.
So for now, my thinking is that it is/was likely a programmer faux pas and not something that might require a Verilog fix.
Is this extra byte TX at start still an issue ?
Does it change at all with baud rate ?
(an earlier post mentioned two Baud formula ?)
What is the timing of the extra Char, relative to reset-exit ?
http://forums.parallax.com/discussion/comment/1394340/#Comment_1394340
That's the one I was looking for. Thanks!
BTW I have found testing with P1V images on A7 & A9 has shown some of the RGB led's are faulty anyway.
Was just thinking about stuff I could play around with in the GUI.
Still have several green LEDs and some buttons...
Noy surpising considering the large Cyclone V FPGA on the board.
I replaced my RGB leds's and verified their operation using a P1V image.
The first set (FLTx) clear the DIR bit to float the pin (and affect OUT), while the second set (DRVx) set the DIR bit to drive the pin (and affect OUT):
CCCC 1101011 CZL DDDDDDDDD 001010000 ** FLTL D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001010001 ** FLTH D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001010010 ** FLTC D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001010011 ** FLTNC D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001010100 ** FLTZ D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001010101 ** FLTNZ D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001010110 ** FLTN D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001010111 ** FLTIN D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011000 ** DRVL D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011001 ** DRVH D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011010 ** DRVC D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011011 ** DRVNC D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011100 ** DRVZ D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011101 ** DRVNZ D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011110 ** DRVN D/# {WC,WZ} CCCC 1101011 CZL DDDDDDDDD 001011111 ** DRVIN D/# {WC,WZ}I'm almost done with the new PLL setup for the clock pins. After that, we are ready to make the chip. Still waiting for word from OnSemi, though, about the nature of their fuses.
However, when you float a pin, there is only one action, ie the pin floats ?
What does the H/L and C/NC Z/NZ N/IN variants do here ?
Cool. Did a post-VCO divider make it into the Verilog ?
The FLTx instructions are a little weird, in that they bother to set the OUT bit to some state, while clearing the DIR bit, causing the pin to float. This is useful in cases where you want to float the pin, but set it up for output later, so that you don't need to buffer the next output state, just do a DIRH to drive it.
FLTIN and DRVIN clear and set the DIR bit, respectively, while sampling the IN bit state into C/NZ, as do all the other DIRx/OUTx/FLTx/DRVx instructions.
Yes. There's a 6-bit divider for the XI/crystal, a 10-bit divider for the VCO, and a 4-bit post-VCO divider. The only thing that I had to realize was that the change rate for the VCO bias voltage needed to be proportional to the speed of the divided XI/crystal. After understanding that, it was simple. Way simpler than I thought it would be.
Hmm, pondering ... would combining the two functions (DIRx plus OUTx) into one register be okay? Eg:
Cog address $1FA is DIR[P0:P15];OUT[P0:P15]
Cog address $1FB is DIR[P16:P31];OUT[P16:P31]
Cog address $1FC is DIR[P32:P47];OUT[P32:P47]
Cog address $1FD is DIR[P48:P63];OUT[P48:P63]
I'm don't know if this limits the Streamer max data width but obviously software bit bashing will be 16-bit data width limited.
As some tech support caller from GM Truck and Bus said to me 20 years ago, "That's a mighty, mighty SUCCULENT idea."
I need to think about the ramifications of doing that. It's no problem for the Streamer to handle that arrangement. I just don't know what it practically means for software. I worry it would cause more awkwardness than it would eliminate. It's very interesting, anyway.
(I often grumble about 32b MCU's having 16b timers, a 32b MCU with 16b ports is rather similar....)
Some MCUs handle the Float/Drive handling by having 4 port modes.
CMOS/OpenDrain/QuasiBiDir/Ip only
N-MOS open drain is done by OpenDrain mode and simple OUT drive, and P-MOS open drain can be managed by select of CMOS<->IP, with OUT=H
Sounds good, and quite competitive now with the NXP offerings
Just thinking some more about SysCLK management across libraries, and from the other thread in handling HyperRAM, which has a 1us or 4us region tCMS.
To auto-manage that in a (eg) HyperRAM RAM-Disk driver, you could define a Crystal value at build time, then
can you then read-back the 6-bit, 10-bit, 4-bit values to extract the current SysCLK ?
How do those 20 bits memory map ?
They go to a write-only register via the CLKSET instruction. On Prop1, we just copied those values to bottom RAM locations.
It can't be any other way, because it takes a few clocks for the pin states to reach INA/INB, then it takes a few clocks for OUT/DIR to reach the pins.
Not so happy with my options...
DE2-115 costs more, doesn't give as much and is way too big.
The BeMicro-A9 seems to have been out of stock for a year.
Are there any small A9 boards with reasonable cost?
Any plans to make more P123 boards?