Dead cog6?
Hiya
Seem to have a problem, but just with COG6. Code below - nice and simple example. It runs on any cog but 6 - I've tried both on a PCB of mine (express PCB) and the prop demo board. Same on both.
Seems to rule out pins and soldering. Stuck. Help?
Debug serial is running on COG 1 and can be verified as if you set the TestCog6 sub to run on 1, you get no output.
???
thanks!
James
Seem to have a problem, but just with COG6. Code below - nice and simple example. It runs on any cog but 6 - I've tried both on a PCB of mine (express PCB) and the prop demo board. Same on both.
Seems to rule out pins and soldering. Stuck. Help?
Debug serial is running on COG 1 and can be verified as if you set the TestCog6 sub to run on 1, you get no output.
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
' debug - USE onboard pins
pcDebugRX = 31
pcDebugTX = 30
' serial baud rates
pcDebugBaud = 256000 ' 57600, 115200 or 256000 only
OBJ
debug : "debug_pc"
VAR
long adcStack[20]
long adcData[20]
PUB Start
' start the PC debug object
debug.startx(pcDebugRX,pcDebugTX,pcDebugBaud)
coginit(6, TestCog6 ,@adcStack)
repeat
debug.str(string("its "))
debug.dec(adcdata[0])
debug.putc(" ")
debug.dec(adcdata[1])
debug.putc(13)
waitcnt(clkfreq/5+cnt)
PUB TestCog6
repeat
adcData[0]++
adcData[1]+=2
waitcnt(clkfreq/10+cnt)
???
thanks!
James
Comments
Generally, it's a bad idea to use coginit. cognew avoids these potential conflicts.
-Phil
How is debug_pc coded in detail?
Does it start a cog with cognew or coginit?
If it does start with cognew it might be that the timing of everything leads to that the cognew inside the debg_pc.spin-file starts cog 6.
then you restart cog 6 through the coginit.
if you use always cognew everything should work because then the prop-chip itself takes a free cog and all cog-conflicts are avoided automatically.
if you start using coginit you the coder take over the responsability to avoid cog-conflicts.
best regards
Stefan
Yes I use coginit (as part of a bigger app) to assign blocks of code to specific cogs to simplify the management (for me).
debug_pc doesn't use a cog - it uses full duplex serial (which is on cog 1) to send debug back to the pc, i.e. debug.str(string("hello world!")), debug.dec(12) etc
I'll double check it and try the other cogs again tonight.
Cheers,
James
On my PCB it doesn't work if you use lots of cognew's - i.e.
cognew(TestCog(2), @adcStack2) cognew(TestCog(3), @adcStack3) cognew(TestCog(4), @adcStack4) cognew(TestCog(5), @adcStack5) cognew(TestCog(6), @adcStack6) cognew(TestCog(7), @adcStack7)
it DOES work however if you start some PASM code in cog 6.....
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 ' debug - USE onboard pins pcDebugRX = 31 pcDebugTX = 30 ' serial baud rates pcDebugBaud = 256000 ' 57600, 115200 or 256000 only ' LED's ledPower = 26 ledStatus = 27 OBJ debug : "debug_pc" VAR long adcStack2[20], adcStack3[20], adcStack4[20], adcStack5[20], adcStack6[20], adcStack7[20] long adcData[20] long i long asm_cog6_tst PUB Start ' starts fullduplexserial on COG(1) debug.startx(pcDebugRX,pcDebugTX,pcDebugBaud) ' start 2...7 coginit(2, TestCog(2), @adcStack2) coginit(3, TestCog(3), @adcStack3) coginit(4, TestCog(4), @adcStack4) coginit(5, TestCog(5), @adcStack5) ' coginit(6, TestCog(6), @adcStack6) coginit(6,@samplerEntry,@asm_cog6_tst) coginit(7, TestCog(7), @adcStack7) { cognew(TestCog(2), @adcStack2) cognew(TestCog(3), @adcStack3) cognew(TestCog(4), @adcStack4) cognew(TestCog(5), @adcStack5) cognew(TestCog(6), @adcStack6) cognew(TestCog(7), @adcStack7) } repeat debug.str(string("its ")) repeat i from 2 to 7 debug.dec(i) debug.putc("[") debug.dec(adcdata[i]) debug.putc("]") debug.putc(" ") debug.putc("T") debug.dec(6) debug.putc("(") debug.dec(asm_cog6_tst) debug.putc(")") debug.putc(" ") debug.putc(13) waitcnt(clkfreq/5+cnt) PUB TestCog(_ID) repeat adcData[_ID]++ waitcnt(clkfreq/10+cnt) DAT org samplerEntry mov t1_ptr,par ' SPIASM Block again add datajames,#1 ' add 1 wrlong dataJames, par ' write to hub call #wait10ms ' wait 10ms jmp #again ' repeat jump wait10ms mov waitcounter,cnt ' Init 1ms time delay. add waitcounter,delta10ms ' waitcnt waitcounter,delta10ms ' wait for 1ms wait10ms_ret ret ' common t1_ptr long 0 counter long 0 waitcounter long 0 delta10ms long 80_000_000 / 10 dataJames long 0 FIT 496
Anybody? Thoughts?
James
there is the shared HUB-RAM which is shared among all 8 cogs.
all COG-RAM is individual to the cog it belongs to. All 8 cogs are absolutely identical.
So there is really no reason to dedicate a certain cog to a certain task.
if you use only cognew the cog-numbers might change from start to start but it really doesn't matter as all cogs are completely identical.
Can you explain to me in detail what you are doing that makes it nescessary to use a certain cog?
I guess nothing as your understanding of how the propeller works is somewhere middle-deep. (if it would be very deep you would have known that FullDuplexSerial starts a cog)
best regards
Stefan
Tried LED's and via SPIN it doesn't work.
Not doing anything spectacularly complicated, a data logging app, but having manual cogs makes life easier to manage,
James
Based on the evidence you've presented, I suspect that cog 6 could have a bad RAM location.The Spin interpreter uses all of cog RAM. Your PASM program uses just a little bit. Just out of curiosity, though, what happens if you run your program using a lower clock rate --- PLLx8 or PLLx4? (Use 9600 baud to test this.)
-Phil
No change sadly. Tried:
CON _clkmode = xtal1 + pll8x _xinfreq = 5_000_000
and
CON _clkmode = xtal1 + pll4x _xinfreq = 5_000_000
-Phil
You need to read his comments: he said the code does work on the Demo Board (post #6).
-Phil
Do try it without the PLL. If that produces the same behavior, you may want to write a program to test all the RAM in cog 6, writing and reading back various data patterns.
-Phil
Same result.
CON _clkmode = xtal1 _xinfreq = 5_000_000
-Phil
Try the attached memory test program.
Dave
http://obex.parallax.com/objects/91/
Runs all COGs, but not all RAM in each COG.
Broken Board:
Cog 2 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 2 memory error at $00C -- $00000001 $00000000 Cog 2 memory error at $00E -- $00000054 $00000000 Cog 3 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 3 memory error at $00C -- $00000001 $00000000 Cog 3 memory error at $00E -- $00000054 $00000000 Cog 4 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 4 memory error at $00C -- $00000001 $00000000 Cog 4 memory error at $00E -- $00000054 $00000000 Cog 5 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 5 memory error at $00C -- $00000001 $00000000 Cog 5 memory error at $00E -- $00000054 $00000000 Cog 6 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 6 memory error at $00C -- $00000001 $00000000 Cog 6 memory error at $00E -- $00000054 $00000000 Cog 6 memory error at $154 -- $C6901B16 $E798F3A1 Cog 6 memory error at $155 -- $4EEDAB57 $D3CB39A3 Cog 6 memory error at $156 -- $89ECA924 $83E0D880 Cog 6 memory error at $157 -- $2C8F53BF $6AD68F68 Cog 6 memory error at $158 -- $83C2DB1A $43A503F0 Cog 6 memory error at $159 -- $FDBE2B5B $86A492CB Cog 6 memory error at $15A -- $02BDA928 $EC35B630 Cog 6 memory error at $15B -- $78CFD3BB $9FE15BC7 Cog 7 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 7 memory error at $00C -- $00000001 $00000000 Cog 7 memory error at $00E -- $00000054 $0000000
on the working Prop Demo board though:
Cog 2 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 2 memory error at $00C -- $00000001 $00000000 Cog 2 memory error at $00E -- $00000054 $00000000 Cog 3 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 3 memory error at $00C -- $00000001 $00000000 Cog 3 memory error at $00E -- $00000054 $00000000 Cog 4 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 4 memory error at $00C -- $00000001 $00000000 Cog 4 memory error at $00E -- $00000054 $00000000 Cog 5 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 5 memory error at $00C -- $00000001 $00000000 Cog 5 memory error at $00E -- $00000054 $00000000 Cog 6 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 6 memory error at $00C -- $00000001 $00000000 Cog 6 memory error at $00E -- $00000054 $00000000 Cog 7 memory error at $007 -- $A0BC1A07 $A0BC1A00 Cog 7 memory error at $00C -- $00000001 $00000000 Cog 7 memory error at $00E -- $00000054 $0000000
EDIT: The second listing is identical to the first. Are you sure it's from the working board?
Essentially running:
coginit(2, TestCog(2), @adcStack2) coginit(3, TestCog(3), @adcStack3) coginit(4, TestCog(4), @adcStack4) coginit(5, TestCog(5), @adcStack5) coginit(6, TestCog(6), @adcStack6) coginit(7, TestCog(7), @adcStack7) PUB TestCog(_ID) repeat adcData[_ID]++ waitcnt(clkfreq/10+cnt)
with or without some LED blinking code in each cog. Cog [0] (main cog) just debugs adcData[2..7] to the serial terminal (cog1)
James
Yes - sorry copy & paste failure. I've updated the post....
Thanks for that - very useful testing.
James
-Phil
Your initial post said that you are having the same errors on the Prop Demo board as on your board. Then what is the cause on the Demo Board? Now that it is known that the other has bad cog mem.
Anyone have an idea what would cause this?
I think I'll save Dave's memory test program in case any of my Props start acting strange.
But a couple posts down Javalin mentions that is does run ok on the Demo board. There is a typo in the first post...
Bad testing on my part - sure I tested both the same, but must of made a mistake. The Demo board is fine for total clarification.