XT control board - build issues

Hello everyone,

So now I have a nice non-shorted voltage rail on my XT control board. I’ve measured VCC at all relevant IC pins and it seems just fine. Things seem to be all good in that way. BUT, i noticed that in removing my OLED earlier, I knocked off one of the SMD components on the back, so I’m writing it off as dead.

My question is this: Should the XT work without a screen attached?

When I power up, I get all LEDs lit, but pressing buttons does not cause any change in which LEDs are lit.

I flashed the ATMega (Bootloader, OS and factory patches) at work using a beeprog, which verified successfully, so I’m assuming that is not the problem.

Any thoughts?

Thanks a lot,
Pete.

On power-up, the content in the shift registers is pretty much random. So it doesn’t mean anything, when you get lit leds.

Did you flash the processor in-circuit? If yes, then the processor should be running fine. If not, then you might have a problem around the crystal and maybe the processor isn’t even running.
Best way to check is trying to read the flash when the chip is inserted into the socket on the pcb. If it doesn’t respond, it might not be running at all.

Did you program the fuse-bits as well?

> Should the XT work without a screen attached?

Yes.

Thank you both!

The leds are not randomly lit, they all light up. But I doubt that makes any difference.

I flashed it out of circuit, in a programmer we have at work. I don’t have a avr programmer.

Also, I doubt I programmed the fuse bits, as I don’t even know what that means :slight_smile: I guess that’s the next step.

Thanks again

The fuse bits control some important things. One of them being internal or external clock, so it can affect how fast the ATmega runs.

So I have worked out how to set the fuse bits. But I just noticed that when I’m importing the hex files into the programmer software, I have two optinos for .hex files: “Straight Hex” and “IntelHex”. What is loaded into the buffer in the programmer software differs depending on what I choose.

Any clues on which to load the shruthi hex files as?

Intel

A thousand thankyous

OK, so some progress…

I flashed the ATMega, now with fuse bits, and when I plug it in… Magic! LEDs that respond to button pushes, sound in response to midi messages, and changes in sound in response to knob tweaks.

Now, the sound was not great. It sounded pretty digitally fucked up, although I could hear the filter cutoff sweep etc, so it was a start. Until the whole board hung after about 5 minutes. And wouldn’t start back up. I was just getting the random LED behaviour again on powering up.

Confused, I re-flashed the Atmega, and it worked again! For around 5 minutes, then it froze and I’m back in the same position.

I’m not in a great position for debugging, as I currently don’t have a screen. But, can anyone suggest what might happen that re-flashing could fix? What can change during normal operation? Could the bootloader be overwritten by mistake if I haven’t set the lock bits?

Cheers,
Pete

Btw, I wasn’t sending anything but midi note data, so I wouldn’t expect anything to be overwritten on the Atmega.

Sorry, this is not a problem I’ve ever encountered…

Dang! Thanks Olivier.

Did I read in another post that different modes can be entered by powering on with a button held (shruthi-1, XT)? I looked but couldn’t find it again. I wondered if it was that?

Otherwise, I’ll just wait for my screen to arrive and see what’s what. Probably get an AVR isp programmer too, so I can flash without taking it into work every time :slight_smile:

> I wondered if it was that?

This wouldn’t explain the failure after 5 min of use.

Regarding the harsh, digital noise… Which filterboard are you using and have you selected the right filter board in the menu?

It’s the 4PM board, and I haven’t selected the correct board; I stupidly broke my original OLED and am waiting for a new one to arrive :confused:

I’ll flash it again tomorrow, and will experiment with the lock bits. I tried the value 2F from the bootloader makefile, but the programmer software wouldn’t accept it, and looking at the data sheet for the 644, I couldn’t make sense of that value either

there are fuse bit calculators all over the web. Be carefull, there is a fusebit that disables the programming interface and you dont wanna flip that by accident. AFAIK the only important thing is to set the oscillator to external high-freq crystal with full swing. For the startup time, you are safe if you choose a high value.
Brown-out detection is not something you’ll need, so you can disable that.

There are avrdude commands here in several threads on the forums, you might want to check those for the right settings

So it’s full a full swing cystal oscillator? The LFUSE bit in the bootloader makefile on github is:

FF - with description “Ext. crystal osc. >8Mhz, startup time: 16K CK + 65ms”

I’ve also seen others on the forum post about flashing the same fuse bit with success.

However, to specify a FULL SWING crystal, then I would have to set LFUSE to:

F7 - “Ext. full swing crystal, startup time: 16K CK + 65ms”

I’m using this crystal, which is the same for Shruthi 1 and XT as far as I can see.

http://www.engbedded.com/fusecalc/

I can replicate what you say, when I have the “devide clock by 8 internally” box checked. That must be unchecked. Then you get 0xFF

Nah, that’s 7F, for the “divide clock by 8 internally” check.

If you select “Full Swing Oscillator” with the same start up times, you get F7.

In your previous post, you said it was important that it was set to an ext osc with full swing. There is distinct and specific option for a full swing external osc, and it reults in F7, rather than FF. I was just wondering if this difference could be the cause of my weird problem?

Hmmmm, Google-fu shows a few people saying “just go full-swing and be done with it”. I think I’ll flash the LFUSE F7 and see if that fixes things.