I don't yet have revb silicon to test with but, as @RossH said, the demo code does have commented out code that sets the revb smart pin mode. Switching to the alternate wrpin and wxpin settings should satisfy the revb USB NCO configuration
I don't yet have revb silicon to test with but, as @RossH said, the demo code does have commented out code that sets the revb smart pin mode. Switching to the alternate wrpin and wxpin settings should satisfy the revb USB NCO configuration
Thanks Garry. Tried all that. No luck. I'm actually beginning to wonder whether my RevB board might be faulty.
Hopefully someone else will try it for us.
If Chip has verified P2 ES2 code, maybe he can post that for you to check ?
Did you check D+/D- connection ? ISTR some chatter around leaving off USB Data resistor-jumpers on the P2-USB connector (to avoid confusing power supplies, in alarming ways...)
Did you check D+/D- connection ? ISTR some chatter around leaving off USB Data resistor-jumpers on the P2-USB connector (to avoid confusing power supplies, in alarming ways...)
I think you are probably talking about the on-board USB ports. I am using the 64006-ES USB Host adaptor board, and this works on the RevA board. I have also tried it on different pins on both boards, in case some individual pins were faulty. So I don't think that would be it.
If Chip could post his modified code (which apparently works) that might help identify the problem. Very likely there is some other change he has made to Garry's code that he forgot to mention.
Did you check D+/D- connection ? ISTR some chatter around leaving off USB Data resistor-jumpers on the P2-USB connector (to avoid confusing power supplies, in alarming ways...)
I think you are probably talking about the on-board USB ports. I am using the 64006-ES USB Host adaptor board, and this works on the RevA board. I have also tried it on different pins on both boards, in case some individual pins were faulty. So I don't think that would be it.
If Chip could post his modified code (which apparently works) that might help identify the problem. Very likely there is some other change he has made to Garry's code that he forgot to mention.
Ross.
I've looked and I can't find it. I must have deleted it after I mod'd it and proved it. One problem was that the version of PNut that I'm using has different operators, like |< is now DECOD, and >< is now REV. I remember that all I had to do was change the operators and comment or uncomment some line that selected the Rev B silicon. Once I did those things, it worked fine.
I've looked and I can't find it. I must have deleted it after I mod'd it and proved it. One problem was that the version of PNut that I'm using has different operators, like |< is now DECOD, and >< is now REV. I remember that all I had to do was change the operators and comment or uncomment some line that selected the Rev B silicon. Once I did those things, it worked fine.
I don't think it can be because of the operators, because the same operators (which are not used in the Rev B specific code sections anyway) work on the Rev A board when compiled by PNut_v33k.
Perhaps your internal version of PNut has another difference?
I've just given the fastspin compiled version with dual port support a run up on both revA and revB Eval boards. On revA I can plug a mouse in either port and get a readout of position no issue.
Swapping the commented section and change from -2a to -2b compile option in fastspin, on revB I get the following:
I've just given the fastspin compiled version with dual port support a run up on both revA and revB Eval boards. On revA I can plug a mouse in either port and get a readout of position no issue.
Swapping the commented section and change from -2a to -2b compile option in fastspin, on revB I get the following:
When you are probing around the board near the breakout board pins and are worried you might short the 5V to a signal pin. It would be an easy thing to do by mistake. It's handy to have this jumper as a protection, but you do need to remember to install it when you want the 5V.
@garryj and (perhaps @ersmith ). It appears there is some type of memory bug in the USB code using Fastspin. I am seeing X,Y mouse delta values being written to a structure in a VAR block outside of the USB spin module. I found it when adding the mouse to my video driver. In my own top level driver I have a structure in the VAR block that defines the screen/mode etc and when I was moving the USB mouse the screen would go haywire. Turned out that it was because it was being overwritten. If I move a dummy array to be the first element of the VAR block in my driver it protects the driver as that array is then overwritten instead and the screen was stable. I shouldn't need to do this however.
Perhaps VAR blocks from different SPIN modules can somehow overlap in FastSpin, or somehow the USB driver is writing into an area it shouldn't be? Hopefully it is just the latter case and can be fixed.
My video driver uses these VARs:
VAR
long dummy[100] ' <--- only put in to protect my critical video structures below from USB mouse data overwrite
long region[13] ' <--- gets corrupted when the dummy array is not present above
long display[15]
long region2[13]
The USB mouse polling example Spin code was taken from KbMObjTest.spin2 and altered slightly to allow me to compute X,Y values and retrieve them (code attached below). It still only uses one VAR.
VAR
long usbA
Finally the underlying low level USB driver (1CogKbM.spin2 with revB smartpins) uses these VARs.
VAR
long usbcog
' Paramter block start address passed to the USB cog via COGNEW parameter
long mouseData
long itemAddr
long itemCount
long dataVals[32] ' Contiguous cog/lut register/cell values
' Parameter block end
When I run my video driver to debug this I dumped the content of the added dummy array before USB is started, and it starts with zeroes.
Then I start the USB mouse driver and continuously display the contents of dummy array after USB is started and when the USB mouse is moved it shows overwritten memory.
00074C94 : 00000005 00FE0100 <<-- second long is mouse +x/-y deltas, values change as I move the mouse.
00074C9C : 00000000 00000000
00074CA4 : 00000000 00000000
00074CAC : 00000000 00000000
00074CB4 : 00000000 00000000
00074CBC : 00000000 00000000
00074CC4 : 00000000 00000000
00074CCC : 00000000 00000000
00074CD4 : 00000000 00000000
00074CDC : 00000000 00000000
00074CE4 : 00000000 00000000
00074CEC : 00000000 00000000
00074CF4 : 00000000 00000000
00074CFC : 00000000 00000000
00074D04 : 00000000 00000000
00074D0C : 00000000 00000000
00074D14 : 00000000 00000000
00074D1C : 00000000 00000000
00074D24 : 01003005 00000000 <- not sure what this value is but it is affected too
So something is clobbering memory where it shouldn't. Do you know why @garryj? Should the USB driver write to the very start of the VAR block?
Looks like the lowest line in red is the usbA var from the usbmouse.spin2 driver and the data values line up (last byte is COG ID, top byte is mouse connected). The question then becomes why do the different top level + lowest level VAR blocks overlap. Perhaps this is actually a question for @ersmith if it is Fastspin related?
I also had problems with including Sub-Objects with FastSpin, in my case I had some offset of 52 longs, but that is a couple of month ago and I had to pass the needed value from the top object down to my PASM code in a sub object.
@rogloh : I know of no reason that addresses in sub-objects would come out wrong in fastspin, and in the simple tests I've performed they work fine. That said, of course I cannot rule out a bug without having the full source code; are you able to share it?
@msrobots : the bug you described with sub-objects was fixed a long time ago, as far as I know. If you're still having problems, could you please post a bug report with an example? If there is an issue I would like to fix it.
Thanks Evan but I don't want to go flailing about trying to reconstruct Roger's problem by piecing together old versions. I'm hoping to get exactly the code that gave him the error he reported on this thread so that I can try to debug it.
@rogloh : I know of no reason that addresses in sub-objects would come out wrong in fastspin, and in the simple tests I've performed they work fine. That said, of course I cannot rule out a bug without having the full source code; are you able to share it?
@msrobots : the bug you described with sub-objects was fixed a long time ago, as far as I know. If you're still having problems, could you please post a bug report with an example? If there is an issue I would like to fix it.
Thank Eric. It's been a few days and my app changed a bit, but I will try to resurrect it back to have the bug back again (shouldn't be hard) and get your the source and listing file etc. Will get to it shortly.
Thanks Eric, same with me, I found a workaround and do not have the old code anymore, had to do with TAQOZ driver and since you put that serial scripting in I see a complete new way to use TAQOZ ROM.
I can start TAQOZ, send serial the mailbox words, TAQOZ mutes its serial and listen to the mailbox at say $10000. And the last command will start a COG at $10008.
And I compile a FastSpin binary at Org $10008 leaving space for the two long mailbox for TAQOZ.
One way or the other, but the TAQOZ in ROM needs to be accessible as Object, I have a couple of more Ideas, just not the time.
@ersmith here is the code that reproduces this USB bug on my system, plus binary, plus listing etc. Top level source file is bugtest.spin2.
You can make the VAR corruption problem happen with or without the mouse present, or with/without VGA breakout fitted etc. If you actually want to see this simple little demo working, fit the VGA breakout on pins 8-15 and dual USB breakout on pins 48-55 (lower port used for mouse), and comment out the infinite serial dump loop that showed the error. You should see the USB mouse moving on the screen and some region scrolling if you click the buttons.
Also if you remove the dummy VAR that protects the important region structure from being clobbered in bugtest.spin2 you can get the VGA to crash when you move the mouse.
This might still be a USB driver problem, or a Fastspin problem, or how the USB code is using Fastspin. I am not sure.
One possibility of why you may not have encountered it before if this turns out to be a Fastspin problem, is that this code uses multi-level deep nesting of spin files and the deepest module's VAR blocks data seems to overlap with the first VAR block. That just might be a special case perhaps.
I got it working on rev B with custom PCB.
But I see another problem: slew rate of data pins.
For USB low speed, it is ok. not great, ok.
For high speed, it doesn't work. The pins of P2 are too slow. I measured 600ns to get a high signal.
The connected USB keyboard gives a near perfect signal back after 1m of questionable logitech cable.
On the hardware I have a capacitor on every power supply pin and I don't measure any drop of voltage.
I think I saw something of a slew rate limiter in the P2, but I can't find it.
Does anyone else has this problem?
The I/O pin should transition in 250ps, unloaded. 600ns indicates it's capacitively loaded somehow. "Full-speed" is the top end of what is possible on the P2, and that signals at 12MHz. So, that needs faster than ~30ns transitions, I think.
I just wanted to send you some pictures from scope and PCB.
Then I saw the fault. I put 100R resistors in series with the pin as protection. But somehow 1k was used.
swapped it with 100R and it all came to live.
Full speed USB. I love propeller!
@ersmith Did you get a chance to take a look yet? It is definitely a bug and reproducable. At times the USB code is writing its output to the wrong location which crashes the code. I can't tell yet whether it is a bug in Fastspin or the USB code, but it could be in Fastspin and I'm leaning towards that now. The USB code is not using the address it is being configured to use but something different. I am sort of wondering if it might be alignment related given it can go away when I change the length of the SPIN code when I add debug code to return an address...
PUB start(mx, my)
maxx:=mx
maxy:=my
cognew(mouseinit, @usbstack)
return @usbA ' <--- when I included this line to debug the code and let me print addresses etc, it wouldn't fail and it would write to the correct VAR address etc, but when I remove it it does fail by writing to the wrong location of the first VAR in a different (and top level) module.
Comments
Thanks Garry. Tried all that. No luck. I'm actually beginning to wonder whether my RevB board might be faulty.
Hopefully someone else will try it for us.
If Chip has verified P2 ES2 code, maybe he can post that for you to check ?
Did you check D+/D- connection ? ISTR some chatter around leaving off USB Data resistor-jumpers on the P2-USB connector (to avoid confusing power supplies, in alarming ways...)
I think you are probably talking about the on-board USB ports. I am using the 64006-ES USB Host adaptor board, and this works on the RevA board. I have also tried it on different pins on both boards, in case some individual pins were faulty. So I don't think that would be it.
If Chip could post his modified code (which apparently works) that might help identify the problem. Very likely there is some other change he has made to Garry's code that he forgot to mention.
Ross.
I've looked and I can't find it. I must have deleted it after I mod'd it and proved it. One problem was that the version of PNut that I'm using has different operators, like |< is now DECOD, and >< is now REV. I remember that all I had to do was change the operators and comment or uncomment some line that selected the Rev B silicon. Once I did those things, it worked fine.
I don't think it can be because of the operators, because the same operators (which are not used in the Rev B specific code sections anyway) work on the Rev A board when compiled by PNut_v33k.
Perhaps your internal version of PNut has another difference?
Otherwise, I'm a bit stumped
Swapping the commented section and change from -2a to -2b compile option in fastspin, on revB I get the following: Which is the same initial messages as revA ... but revA has more, reporting a mouse connected and so on.
I haven't tried the dual port version on Rev B. I'll do that now.
Done: Same result
Yes, I had to get a copy of that file as well.
I am somewhat relieved that it doesn't seem to be just my board!
Ross.
The RevB board has a jumper that says ACC HDR 5V. I never noticed that the jumper was not actually installed - D'oh!
USB drivers (both one and two port) now working as advertised on both RevA and RevB boards!
Thanks, Garry!
Under what circumstances would you not want it installed?
Perhaps VAR blocks from different SPIN modules can somehow overlap in FastSpin, or somehow the USB driver is writing into an area it shouldn't be? Hopefully it is just the latter case and can be fixed.
My video driver uses these VARs:
VAR long dummy[100] ' <--- only put in to protect my critical video structures below from USB mouse data overwrite long region[13] ' <--- gets corrupted when the dummy array is not present above long display[15] long region2[13]The USB mouse polling example Spin code was taken from KbMObjTest.spin2 and altered slightly to allow me to compute X,Y values and retrieve them (code attached below). It still only uses one VAR. Finally the underlying low level USB driver (1CogKbM.spin2 with revB smartpins) uses these VARs. When I run my video driver to debug this I dumped the content of the added dummy array before USB is started, and it starts with zeroes.00074C94 : 00000000 00000000
00074C9C : 00000000 00000000
00074CA4 : 00000000 00000000
00074CAC : 00000000 00000000
00074CB4 : 00000000 00000000
00074CBC : 00000000 00000000
00074CC4 : 00000000 00000000
00074CCC : 00000000 00000000
00074CD4 : 00000000 00000000
00074CDC : 00000000 00000000
00074CE4 : 00000000 00000000
00074CEC : 00000000 00000000
00074CF4 : 00000000 00000000
00074CFC : 00000000 00000000
00074D04 : 00000000 00000000
00074D0C : 00000000 00000000
00074D14 : 00000000 00000000
00074D1C : 00000000 00000000
00074D24 : 00000000 00000000
Debug code for doing that is this:
ser.start(63, 62, 0, baud) waitcnt(cnt+252000000*1) ser.printf("Hello world\n") printhex(@dummy, 100, 4) mouse.start(640-1,480-1) ' <- starts the mouse polling + USB repeat waitcnt(cnt + 252000000) ser.printf("-----\n") printhex(@dummy, 100, 4)Then I start the USB mouse driver and continuously display the contents of dummy array after USB is started and when the USB mouse is moved it shows overwritten memory.00074C94 : 00000005 00FE0100 <<-- second long is mouse +x/-y deltas, values change as I move the mouse.
00074C9C : 00000000 00000000
00074CA4 : 00000000 00000000
00074CAC : 00000000 00000000
00074CB4 : 00000000 00000000
00074CBC : 00000000 00000000
00074CC4 : 00000000 00000000
00074CCC : 00000000 00000000
00074CD4 : 00000000 00000000
00074CDC : 00000000 00000000
00074CE4 : 00000000 00000000
00074CEC : 00000000 00000000
00074CF4 : 00000000 00000000
00074CFC : 00000000 00000000
00074D04 : 00000000 00000000
00074D0C : 00000000 00000000
00074D14 : 00000000 00000000
00074D1C : 00000000 00000000
00074D24 : 01003005 00000000 <- not sure what this value is but it is affected too
So something is clobbering memory where it shouldn't. Do you know why @garryj? Should the USB driver write to the very start of the VAR block?
Hierarchy is this:
hypvga.spin2
|-p2videodrv.spin2
|-SmartSerial.spin
|-Hyper.spin2
|-usbmouse.spin2
|-|-1CogKbM.spin2
Mike
@msrobots : the bug you described with sub-objects was fixed a long time ago, as far as I know. If you're still having problems, could you please post a bug report with an example? If there is an issue I would like to fix it.
Thanks Evan but I don't want to go flailing about trying to reconstruct Roger's problem by piecing together old versions. I'm hoping to get exactly the code that gave him the error he reported on this thread so that I can try to debug it.
Thank Eric. It's been a few days and my app changed a bit, but I will try to resurrect it back to have the bug back again (shouldn't be hard) and get your the source and listing file etc. Will get to it shortly.
I can start TAQOZ, send serial the mailbox words, TAQOZ mutes its serial and listen to the mailbox at say $10000. And the last command will start a COG at $10008.
And I compile a FastSpin binary at Org $10008 leaving space for the two long mailbox for TAQOZ.
One way or the other, but the TAQOZ in ROM needs to be accessible as Object, I have a couple of more Ideas, just not the time.
Mike
You can make the VAR corruption problem happen with or without the mouse present, or with/without VGA breakout fitted etc. If you actually want to see this simple little demo working, fit the VGA breakout on pins 8-15 and dual USB breakout on pins 48-55 (lower port used for mouse), and comment out the infinite serial dump loop that showed the error. You should see the USB mouse moving on the screen and some region scrolling if you click the buttons.
Also if you remove the dummy VAR that protects the important region structure from being clobbered in bugtest.spin2 you can get the VGA to crash when you move the mouse.
This might still be a USB driver problem, or a Fastspin problem, or how the USB code is using Fastspin. I am not sure.
One possibility of why you may not have encountered it before if this turns out to be a Fastspin problem, is that this code uses multi-level deep nesting of spin files and the deepest module's VAR blocks data seems to overlap with the first VAR block. That just might be a special case perhaps.
But I see another problem: slew rate of data pins.
For USB low speed, it is ok. not great, ok.
For high speed, it doesn't work. The pins of P2 are too slow. I measured 600ns to get a high signal.
The connected USB keyboard gives a near perfect signal back after 1m of questionable logitech cable.
On the hardware I have a capacitor on every power supply pin and I don't measure any drop of voltage.
I think I saw something of a slew rate limiter in the P2, but I can't find it.
Does anyone else has this problem?
Then I saw the fault. I put 100R resistors in series with the pin as protection. But somehow 1k was used.
swapped it with 100R and it all came to live.
Full speed USB. I love propeller!
@ersmith Did you get a chance to take a look yet? It is definitely a bug and reproducable. At times the USB code is writing its output to the wrong location which crashes the code. I can't tell yet whether it is a bug in Fastspin or the USB code, but it could be in Fastspin and I'm leaning towards that now. The USB code is not using the address it is being configured to use but something different. I am sort of wondering if it might be alignment related given it can go away when I change the length of the SPIN code when I add debug code to return an address...