Dead cog6?

Javalin · 2011-03-23 12:34

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.

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

Phil Pilgrim (PhiPi) · 2011-03-23 12:38

Which cog does pc_debug start? Cog 6, perhaps?

Generally, it's a bad idea to use coginit. cognew avoids these potential conflicts.

-Phil

StefanL38 · 2011-03-23 13:51

try a testprogram that starts all eight cogs making different LEDs blink at different frequencies

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

Javalin · 2011-03-24 01:35

Hiya,

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

JasonDorie · 2011-03-24 09:40

If I'm not mistaken, FullDuplexSerial launches a cog. SimpleSerial does not.

Javalin · 2011-03-24 10:17

more testing seems to imply this is just odd. On the prop demo board it just works... Whatever way you do it.

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

StefanL38 · 2011-03-24 10:44

again if you want to check if a cog is dead start all 8 cogs with a simple LED blink program like shown in the PE kit labs

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

Javalin · 2011-03-24 10:56

I do know that full duplex serial (which runs inside debug_pc) runs a cog - please read my initial post again. I've tried it with just "fullduplexserial.spin" too.

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

Phil Pilgrim (PhiPi) · 2011-03-24 11:08

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

Javalin · 2011-03-24 11:12

Hiya Phil,

No change sadly. Tried:

CON
    _clkmode             = xtal1 + pll8x
    _xinfreq             = 5_000_000

and

CON
    _clkmode             = xtal1 + pll4x
    _xinfreq             = 5_000_000

Phil Pilgrim (PhiPi) · 2011-03-24 11:40

Try it without the PLL, just a 5MHz clock. Reduce the baudrate to 2400.

-Phil

davidsaunders · 2011-03-24 11:46

I must ask: How are you testing the same IC on both your board and the Prop Demo Board? The Prop Demo Board uses a SMT, Are you removing and re soldering the Propeller each time you switch tests?

Javalin · 2011-03-24 11:48

no, different physical IC's both SMT, both on professional quality PCB's. All GND and VDD's connected and bypass cap's fitted.

davidsaunders · 2011-03-24 11:59

In this case I do not see how two Propellers would have the same exact physical defect. I have not had any trouble using any COG for any purpose (including 6) unless the cog gets restarted by something else. You have triple checked the code of the objects you are using, and figured the timing of when each new cog is started? To verify that there is no chance that your COG 6 is not getting overwritten by something else?

Phil Pilgrim (PhiPi) · 2011-03-24 12:05

David,

You need to read his comments: he said the code does work on the Demo Board (post #6).

-Phil

Javalin · 2011-03-24 12:07

DavidSaunder -> please read my earlier post(s).

Phil Pilgrim (PhiPi) · 2011-03-24 12:09

James,

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

Javalin · 2011-03-24 12:10

Phil Pilgrim (PhiPi) wrote: »

Try it without the PLL, just a 5MHz clock. Reduce the baudrate to 2400.

-Phil

Same result.

CON
    _clkmode             = xtal1
    _xinfreq             = 5_000_000

Phil Pilgrim (PhiPi) · 2011-03-24 12:21

As a control, did you make sure the modified program worked with another cog?

-Phil

Dave Hein · 2011-03-24 12:22

Phil Pilgrim (PhiPi) wrote: »

... you may want to write a program to test all the RAM in cog 6, writing and reading back various data patterns.

James,

Try the attached memory test program.

Dave

davidsaunders · 2011-03-24 12:23

Ok I read your previous posts, and my statement stands. Or have you done a test that uses only one simple Object, written by you, copied on all eight cogs? (Not clear from your posts) Is this how you did the LED tst?

Publison · 2011-03-24 12:23

Just for giggles, you might try the "8-Talking COG's" Object in the OBEX:

http://obex.parallax.com/objects/91/

Runs all COGs, but not all RAM in each COG.

Javalin wrote: »

Same result.

CON
    _clkmode             = xtal1
    _xinfreq             = 5_000_000

Javalin · 2011-03-24 12:41

Not a great result..... Assuming code works as designed...

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

Dave Hein · 2011-03-24 12:49

The "errors" at locations $007, $00C and $00E are intentional just to see if the program is working. The errors on cog 6 at $154 to $15B should not occur. It looks like cog 6 has some bad memory locations.

EDIT: The second listing is identical to the first. Are you sure it's from the working board?

Javalin · 2011-03-24 12:58

DaveSaunders - Yes I have - look at my post @ Today 05:17 PM

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

Javalin · 2011-03-24 13:02

Dave Hein wrote: »

The "errors" at locations $007, $00C and $00E are intentional just to see if the program is working. The errors on cog 6 at $154 to $15B should not occur. It looks like cog 6 has some bad memory locations.

EDIT: The second listing is identical to the first. Are you sure it's from the working board?

Yes - sorry copy & paste failure. I've updated the post....

Thanks for that - very useful testing.

James

Phil Pilgrim (PhiPi) · 2011-03-24 13:07

That's certainly a weird failure pattern. Usually with memory problems you may see one or two stuck bits, but those are all over the place.

-Phil

davidsaunders · 2011-03-24 13:13

Javalin:
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.

Duane Degn · 2011-03-24 13:22

I've been following the Propeller forum for several years. I can't recall ever seeing someone have a memory problem before.

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.

RobotWorkshop · 2011-03-24 13:26

davidsaunders wrote: »

Javalin:
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.

But a couple posts down Javalin mentions that is does run ok on the Demo board. There is a typo in the first post...

Javalin · 2011-03-24 13:27

davidsaunders wrote: »

Javalin:
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.

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.

Dead cog6?

Comments