DIN suspected in loop scandal...

[Jidis]

Hi again,

I've been playing around with some basic loop/counter junk in the SDCC skeleton and have hit a couple weird bumps. Strange part is, there's a board of similar configuration here at home, which doesn't exhibit the same behavior.

As a couple examples:

This (thrown into "NotifyToggle")-

if(!pin_value){  //ignore release

for(count=0 ; count <= 0x0F ; count++)

        MIOS_DOUT_PinSet1(count),
        MIOS_Delay(75),
        MIOS_DOUT_PinSet0(count),
        MIOS_Delay(75);
}

somehow manages to reset the "count" variable when it hits the 16th LED, and loops indefinitely.

Another confusing find was that a routine (also in "Toggle") set to increment a counter and trigger incrementing DOUT pins with each subsequent toggle call would trigger 1,2,...7,8/9,10,11 with pins 8&9 being triggered back-to-back automatically from a single button press.

Additional notes:

That first LED sequence somehow works fine if called from elsewhere (like in NotifyReceivedEvent). Limiting the counter range doesn't help either. It just loops less lights indefinitely.

The home board and the problem board are both running 18F452 variants and MIOS 1.9c. The problem board has two DOUT ICs and one DIN. The home one has two DOUTs and four DINs, but the apps are always set for SRIO_NumberSet(2). I'm pretty sure all my pullups and termination on the DIN chain is OK, but I can remove the board and check if that could be involved.

Much Thanks,

George

[stryd_one]

How'd you go with this? did you get to swap the hardware and see if it replicates the fault?

[Jidis]

Hey Stryd,

I actually took another box over there cause I wanted to play with some pot stuff, and there weren't any on that problem board. So now, two boxes don't do it, and one does. I'm still wondering what it's about. I can try swapping chips maybe tomorrow night, along with looking over the DIN/DOUT board. It just seems weird that it works fine for other stuff.

Take Care,

George

[TK.]

75*2*16 results into a delay of more than 2 mS - I guess that the watchdog will reset the chip in this case.

Using MIOS_Delay is not recommented for realtime applications anyhow, it's better to handle this with a timer interrupt.

Best Regards, Thorsten.

[Jidis]

Thanks Thorsten :)

It didn't seem to reset however. The app keeps running and the loop never terminates. IIRC, I think I could hit it with a MIOS reset from MS's debug panel to restart the app and clear the loop. It also works well on two other boxes using the same number of lights.

Been having too much fun playing with C apps to dig that board back out and wire it up unfortunately, so it is still possible that there's an electrical fault or maybe there's a difference in the PICs I'm using. I'll post if I get anything new on it. (and look into alternative means of long delays as you recommended)

Take Care,

George

[Jidis]

Well, I dug that board out again tonight, and it's not the PIC, and it's not the 74hc165 (swapped out both). I may pull the PCB from the board if I've got time, and see if there's anything wrong with the DIN/DOUT board next.

If anybody knows this: One DIN chip (165) and two DOUTs (595s) set in the software as SRIO number= 2 should still be OK right? Seems I've got other stuff running mismatch quantities there, but nothing with 1&2.

Thanks

[Jidis]

;D Here's a weird one for the record books....

Had time to dig a bit further into that board last night, and tried pulling the two DOUT ICs and running with just the DIN half, as switch #8 wasn't working either, and it's path to the 165 seemed OK. Lo and behold, running an MB64 app with no 595s installed, the last LED from DOUT#1 has a mysterious faint "glow" to it. ::)  (thank god for visual indicators)

Turns out a glob of solder on a pin somewhere had bridged itself a link between DOUT pin#15 and DIN pin#6. Not a perfect link, just enough for about 150 ohms between them. I thought I had gotten better about checking my freshly etched boards for shorts and crap, but I guess I need to extend my checks into the "post population" stages.

As if I don't have enough trouble proofreading my newbie C code- now the soldering iron's in there with it. ;)

George