abandoned bytes
Engineering: the art of making what you want from things you can get.

Yaca: one step forward, two steps back

17. Juli 2010

Verzeihung

Todays morning started promising. After about 4 hours of searching for the problem in the control-panel bootloader, it turned out that I was on a different git branch than where I had set the CAN ID of the node, thus it wouldn't answer...

The afternoon wasn't much more productive though. A quickly written CAN-to-serial program for the control-panel was followed by the program christened to yaca-ppp (connects via TCP/IP to the CAN gateway and via pipes to pppd) and another CAN bus outage. This time, however, it was not the CAN gateway that failed, but pool-control. The 7-seg display was showing a single glowing 7, two 7-seg digits were empty (3 digits should be multiplexed in an interrupt).

Moreover, the control-panel bootloader stopped responding once again, and the flash and EEPROM were rubbish as usual. In a desperate attempt, I googled EEPROM corruption, which led me to low supply voltage... which lead me to the question: does the ATmega EEPROM work with 3.3 V? Well, it does. But the ATmega8 is only specified to 8 MHz at 3.3 V, and I'm running it at 14.745 ...

Quickly hooking up the controller to 5 V doesn't really improve the situation though. Altough bit corruptions in the memories have (almost?) disappeared, the bootloader still sets error flag 0x04 (invalid state of the bootloader state machine), which makes you wonder.

Finally, the application doesn't do anything to transfer the incoming CAN bytes to the UART. Maybe I'll try setting a port bit to see whether frames even arrive in the application (which I doubt as entering the bootloader from the application still fails, too). CRAP.

Kommentare

Noch keine Kommentare. Warum schreibst Du nicht den ersten?

© 2009 by David Madl. Impressum | Home (English) | Home (Deutsch) | Processing time: 0.364 s | IPv4