I have this puzzling problem that just started with the rf230 radio on one of my ravens.
I routinely use a jtag signature read to reboot contiki to see the startup traffic, and the other day I noticed it occasionally started up in a mode that added bad checksums to all tx packets. Some experimentation showed that reboots done by power cycling always gave the correct CRC (shown by 15dot4 sniffer and wireshark).
Since I was powering the Raven through the ext voltage input using an STK500 at 3v3 which is below specs, I thought maybe cranking that up to 5 volts would fix it. But just the opposite! Now it is completely consistent, checksum errors after signature read reboot, no errors when power is cycled.
It's as if the radio doesn't get initialized properly if the 1284p starts up too fast. But adding waitidle calls before all the register writes (especially the hal_subregister_write(SR_TX_AUTO_CRC_ON, 1) had no effect.
The packets are otherwise correct as shown by wireshark. How can the Dragon JTAG reset be affecting the radio? How can the *hardware* be computing the wrong checksum? I can see how possible dragon/stk500 rs232 ground loops might get worse with higher voltage, but affecting the hardware checksum? The 1284p boot does
[/* Do full rf230 Reset */ hal_set_rst_low(); hal_set_slptr_low(); delay_us(TIME_RESET); hal_set_rst_high();
Interrups are disabled as part of the boot process but timer or radio interrupts can conceivably occur if the jtag signature read does not disable interrupts, but how can any of that affect the radio hardware checksum????