MultiModule help

i've re-soldered the connections between the board and the TX multiple times. I can get continuity with a multimeter across every soldered connection.

if I disconnect any single line, I get errors, so I'm pretty sure i'm getting good solder joints.

thanks

The AVR and programmer DFU's have the right md5 sums. Can't check the nightly build without knowing which nightly build you have. But I'd be surprised if that's the problem.

Is the sum for the AVR.hex file from the version on the Tx, or on your computer, check it on the Tx as well.

Also, why are you using the 1.2 AVR file? The 1.3 is labelled as "for all boards", so it looks like you ought to be using it.

The difference in the displays makes me think there may be an issue with you Tx. But I have a 10, and already had a USBASP programmer, so just used that.

I was initially told to use the "older" AVR for my older, v1.2 board. i have tried the 1.3 AVR as well. it gives the same results, just shows 20bytes when i do the programming. The md5 was from the AVR on the TX.

i have ordered a programmer from Banggood, when it gets here in Sept, i'll let you all know how it goes.

thanks

ok, i took one last shot with what I have. just the multi-module board directly to the TX, with as short a bunch of wires as I could imagine working with and still be able to get the board inside the radio. I get the same results. It will flash the chip, but only 20bytes (using the 1.3 AVR.hex) and on boot it shows module missing.

I don't see, or can't really tell, if there is real good solder flow to the pads on ATtiny side of the MM board. Perhaps after soldering, de-soldering, and re-soldering so many times, one or more pads has separated from its via to the other side? Which is why I suggest continuity and resistance check from the pins of the ATtiny itself to all their points on each board, the main Tx board and the associated transceiver pads of the MM board.

Don't know, just throwing that out there. This has to be completely and totally frustrating for you.

I also noticed the funky text on the 7e display, really strange. Maybe you just have a bum processor on the main board of the Tx right out of the box? Did you use an anti-static wrist strap, work pad, with grounded soldering iron, and follow good practices when handling everything? If not, perhaps you just got unlucky and ESD zapped the processor. ???

Like I said, just putting things out there, because this is a really, really perplexing.

i have not been removing and re-soldering the ATTiny chip. The minimum order of boards from OSH park is 3, so i've actually built the multi-module on two different boards now, with two different ATTiny chips, and two full sets of modules. The only things that have been de-soldered and re-soldered are wires going to the multi-module board from the modules, as I tried different combinations of the modules at first, before it was suggested that I program with just the ATTiny chip on the board. I am 100% that the pads on the boards for the lines to the TX and to the ATTiny chip are still in good shape.

As I can take any two of the modules and solder them back into the TX without the multi-module board, and it works fine for anything I want at that point, I am assuming my CPU is fine. (HiSky, V911 and DSX tested and verified) I also have tried the programming part of this on a second 7e TX unit, a completely separate unit. I soldered in the multi-module board with just the ATTiny chip installed. I get the exact same responses from the TX through the entire process. I have restored that TX to it's "original" state, which is as a 7e with just the nRF24L01 module added for use with the HiSky protocol, and it is again fully functional for its naive protocols and HiSky verified on an HCP80.

I can clearly see that the traces on my Multi-module board are different than either of the boards shown on the wiki. My board is a "Tx Module 1.2, deviationtx.com". Are we sure that either of the AVR.hex files available are for this board?

Also, i assume these radios are fairly stable now, but my backplane board says Wakera DEVO-6F 2.0 on the board itself, and has a white sticker over that with black lettering V0.2A. is it possible this is a new version of something?

thanks

Perhaps reflow the solder on the ATtiny then? ....cold joint maybe?

Well, clearly the v1.2 MM board is programmable via a USBASP programmer and the process that SeBy_DocKy used to do his DEVO, as evidenced by his video.

I think my next step would be to just wait on the cheapo Chinese USBASP programmer, and try that method. Seeing as you can currently fly with another 7e that works with two additional transceivers, without the MM, it shouldn't be too much of a burden to wait on the slow boat from China to bring the one that you ordered to your door. ....and if you really need to fly on a third transceiver, you can just wire it up to the spare 7e.

The "spare" 7e was a loaner that I borrowed (for a 6-pack) to have a second radio to test with, after all the effort I've put in on this had gone nowhere. I just wanted to be sure there was nothing wrong with my radio. As the results are the same, I am going to have to assume there is a defect in the 7e programmer .dfu, as that's clearly where this process is breaking down for me. SeBy_Docky used a Devo 10. As I also tried to use the Devo 10 .dfu on my 7e, and the results were a TX that did not boot at all, I can safely say that there is a difference between the 10 and 7e. Enough of a difference where the fact that it worked for him on his 10, does not guarantee it should also work on the 7e. i have indeed ordered the USB programmer, and once it arrives I will give this another try. In he meantime I have re-installed just the 7105 and nRF24L01 in my original 7e TX and it is working for my v911, my HCP80/100 and Blade Nano once again.

thanks

In looking at the DYI Tx thread (which is based on PB's multimodule design and code), mention was made of the fuses in the ATMega.

Possibly those are wrong and that's causing you problems? Can those be set in the 7E programmer? Given it's restricted use case, possibly it should (or already does) just set them to the right values?

The USBASP programmer will let you read and set those....

i do not know what you are referring to, I am not a programmer. I am currently waiting on a USB device to try programming it that way. As far as I know, the 7e programmer .dfu is not something that takes any options. Editing it's code is beyond my abilities.

thanks

ok, I received the programmer, and I believe I was successful in programming the chip. However, I still get the "module not found multi module" error when I power up the TX. Yes, I edited the hardware.ini file appropriately. I have again verified that all the modules I am using are functional. The multimodule will not be detected by the TX even if it is connected to the TX with no other modules connected to the board.


C:\Users\sam\Desktop>avrdude -p t24 -c usbasp -e -U flash:w:avr.hex

avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x1e910b
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update
.
avrdude: reading input file "avr.hex"
avrdude: input file avr.hex auto detected as Intel Hex
avrdude: writing flash (290 bytes):

Writing | ################################################## | 100% 0.25s



avrdude: 290 bytes of flash written
avrdude: verifying flash memory against avr.hex:
avrdude: load data flash data from input file avr.hex:
avrdude: input file avr.hex auto detected as Intel Hex
avrdude: input file avr.hex contains 290 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.19s



avrdude: verifying ...
avrdude: 290 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done. Thank you.


C:\Users\sam\Desktop>

Yup, that looks like it wrote correctly. Checking the fuse byte(s?) would be a good idea, as they control chip operation. Possibly someone who know what they need to be on the MM can provide instructions on checking them? Or let us know that they don't matter.

i am all but ready to just give up on this altogether. I have now been able to successfully flash the AVR.hex file for both the 1.2 and the 1.3 board. I have built two full multi-modules with the chips that said they were successfully programmed, but neither of them work once soldered into a TX. I have made the appropriate changes to the hardware.ini file, and I can make any two of the modules work just fine when directly soldered to the TX. The only thing I can not make the TX recognize is a multi-module board. Neither with just the chip alone, or fully assembled multi-modules will be recognized by two different TX's. I do not believe I am making any mistakes anymore, and for sure I am not making the same mistake over and over.

just to show, you can see the two fully assembeled boards, and the chip-only board i am using as a programmer as well as the additional modules I have been soldering back and forth.

from the fuse programming step. I got these values from the bitbucket.org/PhracturedBlue/deviation/w...20the%20Multi-Module page.

C:\Users\sam\Desktop>avrdude -p t24 -c usbasp -U lfuse:w:0xe2:m -U hfuse:w:0xdf
m -U efuse:w:0xff:m
avrdude: warning: cannot set sck period. please check for usbasp firmware updat
.avrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.06s
avrdude: Device signature = 0x1e910b
avrdude: reading input file "0xe2"
avrdude: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xe2:
avrdude: load data lfuse data from input file 0xe2:
avrdude: input file 0xe2 contains 1 bytes
avrdude: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xdf"
avrdude: writing hfuse (1 bytes):
Writing | ################################################## | 100% 0.00s
avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xdf:
avrdude: load data hfuse data from input file 0xdf:
avrdude: input file 0xdf contains 1 bytes
avrdude: reading on-chip hfuse data:
Reading | ################################################## | 100% 0.02s
avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xff"
avrdude: writing efuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xff:
avrdude: load data efuse data from input file 0xff:
avrdude: input file 0xff contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.03s
avrdude: verifying ...
avrdude: 1 bytes of efuse verified
avrdude: safemode: Fuses OK
avrdude done. Thank you.

I thought i read somewhere that you have the ATiny84 chip not the 24, if so than you should change t24 in t84.

i have ATTiny 24 chips now.

skretchmer wrote: "avrdude: warning: cannot set sck period. please check for usbasp firmware update".

Isn't this an error in the flashing of the micro-controller?
I still don't think it is flashed correctly. Something is wrong.

Did you re-flow the pins of the ATtiny to confirm good solder joints?

i have done the programming to four boards, with 4 different ATTiny chips. I have tested continuity from the chip leads on top of the board to the programmer pins, and to the TX pins.

yes, i have re-flowed the solder to the chip. The connections to the chip are not the problem.