MIOS keeps rebooting!

MIOS programming (Assembler)
1

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  :frowning:

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

2

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 :slight_smile:

3

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 :slight_smile:

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

4

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? heh

Edit: Oh - Watchdog?

5

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

6

I Wonder if MIOS clears these before you can read them?

From the 18F452 datasheet:

3.0      RESET

The PIC18FXXX differentiates between various kinds

of RESET:

a)  Power-on Reset (POR)

b)  MCLR Reset during normal operation

c)  MCLR Reset during SLEEP

d)  Watchdog Timer (WDT) Reset (during normal

    operation)

e)  Programmable Brown-out Reset (BOR)

f)  RESET Instruction

g)  Stack Full Reset

h)  Stack Underflow Reset

Most registers are unaffected by a RESET. Their status

is unknown on POR and unchanged by all other

RESETS. The other registers are forced to a RESET

state on Power-on Reset, MCLR, WDT Reset, Brown-

out Reset, MCLR Reset during SLEEP and by the

RESET 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 different

RESET situations, as indicated in Table 3-2. These bits

are used in software to determine the nature of the

RESET. See Table 3-3 for a full description of the

RESET states of all registers.

7

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’.

Thanks

Phil

8

Ahh good news :slight_smile:

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?

9

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!

10

Well I gathered as much :slight_smile: 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!