philetaylor Posted November 13, 2008 Report Share Posted November 13, 2008 Hi.I was getting quite close to getting my IIC_DMX512 interface working but I spent most of last night trying to figure out what I have broken that is causing the Core to keep rebooting......I have verified that when I reprogram the IIC PIC with the original IIC_MIDI firmware, it doesn't cause the Core to reboot but put my firmware on it and it does :(I know it is a longshot but does anybody have any suggestions as to what might be causing the Core to reboot, I did wonder whether I was erroneously sending interrupts to the I2C instead of the USART but I don't think so?Phil Quote Link to comment Share on other sites More sharing options...
stryd_one Posted November 13, 2008 Report Share Posted November 13, 2008 Did you recently change something that might have it drawing more power? Change pins? MIOS should handle it if the IIC slave acts up...Hint: save multiple copies of your code at various stages so you can roll back if you break it. Drag them into a zip file to tidy up when youre done, then drag that onto a usb stick. Email milestones to a gmail account. Presto, triplicate incremental offsite backup for the low low price of 5 mouse clicks :) Quote Link to comment Share on other sites More sharing options...
philetaylor Posted November 13, 2008 Author Report Share Posted November 13, 2008 I know I really should take multiple backups at various times, I am usually pretty strict with myself.......I am sure it will be a really silly error but I am damned if I can find it, I even tried using a different PIC in case I had damaged this on by constantly removing it from its socket. I am starting to think I should have bought ZIF sockets for the IIC_MIDI and PIC Burner :-)I think I may start again as I can transplant a lot of the code back into the IIC_SpeakJet package and do it a bit at a time until I find what is causing the blowup!I did try displaying what was coming back to the core from the IIC (using IIC_Midi_Receive in the Tick function) and that appeared to just be one byte of 0xFF. AFAIK, I am not sending 'anything' back to the core so I am not sure how that is getting there? I know 0xFF can be used to put the IIC_MIDI into cmd mode, I wonder if it works the other way round as well?????Phil Quote Link to comment Share on other sites More sharing options...
stryd_one Posted November 13, 2008 Report Share Posted November 13, 2008 FF ... all ones ... short?In case you can't tell, I'm not convinced it's software... But I haven't seen it so WTF would I know? hehEdit: Oh - Watchdog? Quote Link to comment Share on other sites More sharing options...
philetaylor Posted November 13, 2008 Author Report Share Posted November 13, 2008 I did wonder about the watchdog timer, I am doing clrwdt in any of the 'big' loops, is there anything else I should do and would the wdt expiring cause the Core to reboot?????Phil Quote Link to comment Share on other sites More sharing options...
lylehaze Posted November 13, 2008 Report Share Posted November 13, 2008 I Wonder if MIOS clears these before you can read them?From the 18F452 datasheet:3.0 RESETThe PIC18FXXX differentiates between various kindsof RESET:a) Power-on Reset (POR)b) MCLR Reset during normal operationc) MCLR Reset during SLEEPd) Watchdog Timer (WDT) Reset (during normal operation)e) Programmable Brown-out Reset (BOR)f) RESET Instructiong) Stack Full Reseth) Stack Underflow ResetMost registers are unaffected by a RESET. Their statusis unknown on POR and unchanged by all otherRESETS. The other registers are forced to a RESETstate on Power-on Reset, MCLR, WDT Reset, Brown-out Reset, MCLR Reset during SLEEP and by theRESET instruction.Most registers are not affected by a WDT wake-up,since this is viewed as the resumption of normal oper-ation. Status bits from the RCON register, RI, TO, PD,POR and BOR, are set or cleared differently in differentRESET situations, as indicated in Table 3-2. These bitsare used in software to determine the nature of theRESET. See Table 3-3 for a full description of theRESET states of all registers. Quote Link to comment Share on other sites More sharing options...
philetaylor Posted November 14, 2008 Author Report Share Posted November 14, 2008 Well I have found the problem and (not surprisingly) it was my mistake!In a couple of places I was in the wrong bank when I wrote data, I went through my code with a fine tooth comb and late last night (about 2am) I got it working......Just when I think I have got my head round memory management, I find something else that 'bites me'. ThanksPhil Quote Link to comment Share on other sites More sharing options...
stryd_one Posted November 14, 2008 Report Share Posted November 14, 2008 Ahh good news :)So what was causing the reboot then? As I said, MIOS should handle it if the IIC slave screws up... Were you driving the wrong pins/driving the pins to bad levels? Quote Link to comment Share on other sites More sharing options...
philetaylor Posted November 15, 2008 Author Report Share Posted November 15, 2008 I think that I had screwed up my register bank selection so when I thought I was writing to one bank I was writing to another, I think I was basically splatting bits everywhere! Quote Link to comment Share on other sites More sharing options...
stryd_one Posted November 15, 2008 Report Share Posted November 15, 2008 Well I gathered as much :) What I'm asking is, what caused the core to crash when you made an error in the slave module? IE, what were you doing with these splattered bits? I guess if you're not sure where they got splattered to, you won't know... I'm still pretty confident it was a hardware issue, and I'm guessing that you might have overwritten the registers you were writing to the pins for IIC ... Which also explains your mystery 0xFF...Text adventure! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.