MembersPage/NicolasGobet/SerialCommunication/PremierJet

MembersPage/NicolasGobet/SerialCommunication

MembersPage/NicolasGobet


I'm not yet able to communicate with the processor using serial cable.

Some results show that at least NOT everything is dead. Suggestions appreciated


Test to know if uC is stuck in bootloader

Sun070204: I've now been able to catch a signal when the board starts but in 38400,8n1n. See on this picture:

bray38400_8_n_1_n.jpg

I started windows hyperterminal and saw one unknow char each time I started the board:

38400_8_n_1_n.jpg

This, in addition to the fact that uC is heating, tells me that uC is not dead.


Upload of new firmware using serial communication and megaloader

  • You can try to to upload new firmware with or without the -t megaloader (or prog.pl) option, TRY BOTH. Make sure the .bat file has the correct COMx port (like COM4 if that's the one you use)
  • the -t option doesn't work, it is even used as default in the upload-firmware.batin the "VemsMT?1.0.53". after "Translation complete" (which means it interpreted the vems.hex file), the script stays stuck for a few seconds => no success
  • so what happens without the -t ?
  • I tried this, using com1. I'm sure this is com1 because I have only one prt and doc of my motherboard told me that it is "com1". In fact, I also tried with another computer. Removing option -t didn't give great results. I know for sure that I'm not able to communicate
megaloader2.jpg

Sun070204: doesn't work


Upload of new firmware using serial communication and prog.pl

  • to send a new vems.hex without megaloader, perl ...path.../prog.pl vems.hex :COM3 Etw
  • but you should find out x for your COMx -port first, and find out if you get answer in either 19200,8n1 or 9600,8n1 for 'S' (capital S, see above). If megaloader does not work, prog.pl will likely not work either (and it needs serialport library).
  • I tried to send 'S' command in all the baud rate suggested, but I was unsuccessful. I even tried all other rates.
megaloader.jpg

Sun070204: doesn't work


AVR Reflashing using ISPI

The ISPI port can do it. You need to make a cable, such as the popular (STK200 cable) and hook up to a parallel port.

There is nothing vems-specific about this. It is documented in avrdude. Check the

Try dumping part of the flash, like

<code>

avrdude -c stk200 -p m128 -t

dump flash 0 512

<code>

If the ISP-comm test does not work, than the AVR has most likely been fried and little can be done about it.

Sun070204:


Misc ISP and RS232 hints

I'm currently fighting similar problems. I have links for the cable I built and what else I did on MembersPage/EzDi. This method should work as long as your avr has power, and the wiring to the pins on the avr are complete (ie, not missing a resistor for say the pullup on rst).

Sun070204: AVR has power, but doesn't work.

I think that my MAX232 is not dead. When I shortcut pin 1 and pin4 from ISPI (bootloader mod) and connect to my board using com1 and 9600,8n1, I can send char to the board and I get them back:

bray9600_8n1n_bootloader.jpg

-> It appears that I had loopbacked the serial port from my computer...


AVR dead?


Hans: I don't know what was on the V3.1 board from the shop.. but try and see the 2, 3 and 4'th guides on this page: http://www.vems.co.uk/VEMS/


-- Answered Q.