Hello everyone,
I am one of the happy users of Motion boards in my projects.
Still on my first step, just developed a wireless communication system, that uses pin D3 as input with interrupts to read a ppm signal.
during debug phase, I set pin 0 to 13 to INPUT_PULLUP and that to OUTPUT.
After this the board hangs when I call the radio.send routine and I have a ppm signal getting to pin D3.
If the cable to pin D3 is disconnected it works fine (meaning no hanging).
My request for your help is to find a way to reset the Motion to its factory state.
Is there any routine I can run to set it to factory state, where all Registeres related to interrupts, and any GPIO pin be set to its "default" ?
thank you for any help
As in "Low Power Lab Factory state"?
That can mean multiple things. Sounds like you are having some trouble with your sketch and need a fresh start? Just reprogram it with another sketch, would that work?
Or you want to reflash the bootloader? For that you'll need a ISP programmer.
@pedro,
One thing you might want to remember is that some of the digital pins are required for use with the radio and flash chip (if you purchased one).
For example, I don't set the following pins:
D2 - radio interrupt
D8 - flash
D10 - CS for transceiver
D11 - MOSI
D12 - MISO
And, as Felix mentioned, all you need to do is reload a new sketch. The MCU doesn't keep state between sketches, so you don't have to "undo" anything.
D13 - SCK
Thank you Felix and Syrinxtech for you comments.
I initiatively followed your advices, I load a mother sketch and than again my own.
My concern was related to interrupt register that I was afraid I messed up.
I'm just using D3 for PPM input and D4,5 and 6 as Output for debug (as I cannot use Serial.print).
What I could find meanwhile is that my sketch works fine (ppm is well interpreted by ISR) and information is sent by radio.send routine every 15ms and takes about 5ms to transmit.
the PPM input comes from an RC radio.
On the bench everything works fine, yet if I touch with my finger on pin D3 (ppm input) while it is working, the sketch stops!!
What I could isolate is that it "stalls" during transmission, i.e., my radio.send instruction in inside loop().
my ppm reading code is on a ISR routine triggered by int1 (D3) attachInterrupt(digitalPinToInterrupt(PPMIN_PIN), readPPM, FALLING);
When I touch with my finger on D3 pin, the loop() stops and I found that it stop on instruction radio.send(PPMTRAINERID, (const void*)(&lastPPM), sizeof(lastPPM),false);
I debug in by placing output feedback to pin D6 (HIGH before instruction, LOW after instruction), and when it "stalls", the pin D6 is always HIGH, meaning that it does not come out of the radio.send instruction.
I further digged in RFM69.cpp code to find out exactly where it stops.
I found that it gets stuck on the RFM69::sendFrame function on the instruction in bold
// no need to wait for transmit mode to be ready since its handled by the radio
setMode(RF69_MODE_TX);
uint32_t txStart = millis();
while (digitalRead(_interruptPin) == 0 && millis() - txStart < RF69_TX_LIMIT_MS); // wait for DIO0 to turn HIGH signalling transmission finish
//while (readReg(REG_IRQFLAGS2) & RF_IRQFLAGS2_PACKETSENT == 0x00); // wait for ModeReady
setMode(RF69_MODE_STANDBY);
My guest by now is that there may be a interrupt conflict somewhere provoked by noise on D3 pin injected when I touch with my finger.
1st hypotheses:
Conceptually this should not occur, as int0 (D2) used by RFM69 has higher priority and in only for receiving data packets not for transmitting.
2nd hypotheses:
The mills() routine is stopped maybe because of some interrupt disable situation(that I could not yet identify), at the same time that the send does not complete (that I could also not explain).
3rd hypoteses:
the code gets stuck on my ISR routine while it is in mid transmission code. This I could already clear that is not happening . I used the same technic of raising pin(D5) on ISR entry and lower it on exit. When stalled the pin is always down, so I conclude it always exist my ISR routine,but my D6 pin is high (raised inside the sendFrame function just before the while... and never reaches the Lower pin instruction just after the while.
In conclusion (where i am stuck):
Why does the send does not complete after the setMode(RF69_MODE_TX); instruction to satisfy the condition digitalRead(_interruptPin) == 0 ?
Why does it not timeout with the code millis() - txStart < RF69_TX_LIMIT_MS ?
Any suggestion on how to debug this ?
Just out of curiosity, what frequency is the RC radio using?
You mentioned that you cannot use Serial.print()......why not?
Quote from: syrinxtech on May 07, 2016, 10:24:51 AM
Just out of curiosity, what frequency is the RC radio using?
You mentioned that you cannot use Serial.print()......why not?
I am using mostly a 2.4Ghz module from Frisky, but this does happen even with no module on it .
The Moteino Pedro is using works on 433mhz.
yes, that's right, the moteino is a 433Mhz version.
I missed your question about Serial print.
I can't use it to debug the ISR as i'm getting interrupt with 300us to 2000us (micro seconds) and de serial print is to slow even to print just an "*" to make sure the code has been executed.
So i'm using hardware feedback by raising some pin to "see" that code has been executed.
I was really braking my mind with this one :o :o :o
I read a few articles abou interrupts, timers, processor register, so that a could understand and establish registers state as from factory.
actually as you all said , just loading a working sketch (or empty sketch) will assure the correct initialisation on the processor register concerning timers and interrupts. Thank you for your comments on this.
The problem was far from being related to interrupts or timer, was a simple array index off limits.
I was decoding 8 channel and storing in an array [0-7] :D but I was allowing index to reach 8 and when it happened the processor goes nuts. curiously always on same instruction and that was on RFM69::sendFrame(), that I now believe was just a coincidence .
PROBLEM SOLVED :D :D :D
Fantastic....great detective work.