AVR128DB48 unexpected behaviour
defavltt opened this issue · 5 comments
Recently made an audio board based on AVR128DB48 with an oled screen and a boost converter for it. In the beginning everything worked fine. Now the main loop is frozen for most of the time, the rest of the time it runs REALLY slow, but interrupts are working perfectly, since i can hear the audio being sampled from the adc processed and being output from the dac, only the screen is chugging really bad if updating at all, everything else like menu logic and screen writing is done from the loop, in this case i used direct int main() and for(;;).
The single frame written to the screen before going to for(;;) always appeared.
here are the init functions at the beginning of main()
init_clock();
init_ADC0();
initVariant();
This code was developed on a board with the same hardware except with a different screen, no problems there.
Tried just constantly printing a short string with serial in loop(), that also froze after a random short amount of time (1s - 2min).
Also tried playing with startup times, BOD, reducing clock speed and reflashing the bootloader.
I want to know if i damaged the MCU when soldering even though problems came later, i soldered 20-30 of these with no problems at all. How can i fully erase it with or "factory reset it" with just a serial adapter and a resistor for an UPDI programmer, if that even would help? Has anyone encountered this or similar isssues? Can it be fixed without replacing the MCU?
My only idea why this happened is touching the pcb and bridging very lightly the 6 volts from the boost circuit to somewhere else, if this is the problem it would probably just killed it fully?
I would recommend to get a debugger, you can use the curiosity nano dev boards for it (cost about 20 bucks all in all). This would allow you to see where the program hangs.
Anyway, I suspect the problem might be the screen/I2C interface. Even though I have added timeouts, the Wire library is by design blocking the MCU during endTransmission, so removing those would be where I'd start. (Keep the Serial prints, to see if the lock up persists). Or: monitor the lines with an oscilloscope
Second - Add multiple Serial Prints in different parts of your code to see which is the last to be send.
Also, what is your Baud rate and are you clearing the interrupts of the ADC?
I have the curiosity nano board, the problem is in the board that i have designed and ordered online, previous first prototype i made with wires and an spi lcd instead of an oled works fine, the oled is wired in spi mode @ 8mhz (u8g2), no i2c used here.
MCU is 32mhz internal. Now that i played around more, it might be a power supply issue, also i completely disabled the boost converter and power the oled from a lower voltage, this doesnt fix it also, but disconnecting the whole oled panel it almost fixes it.
Also something to note, when the oled can display something, its a little glitched.
There is a timer isr @ 20khz (enough for a conversion to complete) starting a conversion and at the end i clear the intflag.
In that interrupt theres one spi sram read or write function being called. The sram is connected to a different spi port. This is the code for the spi ram, just in case.
#define sram_cs_pin PIN_PB5
#define sram_cs_bit 0b00100000
#define sram_write_cmd 0b00000010
#define sram_read_cmd 0b00000011
void sram_init() {
PORTC.DIRSET = 0b00000101; //set sck and mosi to output
digitalWrite(sram_cs_pin, 1);
pinMode(sram_cs_pin, OUTPUT);
// PORTMUX.SPIROUTEA = 0; //default
SPI1.CTRLB = 0b00000100; //slave select disabled
SPI1.CTRLA = 0b00110001; //enable, clk2x, master //16mhz spi
}
void sram_write_single(uint8_t val) {
SPI1.DATA = val;
while(!(SPI1.INTFLAGS & SPI_RXCIF_bm));
}
uint8_t sram_read_single() {
SPI1.DATA = 0;
while(!(SPI1.INTFLAGS & SPI_RXCIF_bm));
return SPI1.DATA;
}
void sram_write_byte(uint32_t addr, uint8_t val) {
PORTB.OUTCLR = sram_cs_bit; //low
sram_write_single(sram_write_cmd);
sram_write_single((uint8_t)(addr >> 16));
sram_write_single((uint8_t)(addr >> 8));
sram_write_single((uint8_t)addr);
sram_write_single(val);
PORTB.OUTSET = sram_cs_bit; //high
}
uint8_t sram_read_byte(uint32_t addr) {
PORTB.OUTCLR = sram_cs_bit; //low
sram_write_single(sram_read_cmd);
sram_write_single((uint8_t)(addr >> 16));
sram_write_single((uint8_t)(addr >> 8));
sram_write_single((uint8_t)addr);
uint8_t val = sram_read_single();
PORTB.OUTSET = sram_cs_bit; //high
return val;
}
I suspect its a power supply issue or somehow the oled crashes the mcu even without the boost converter.
As you have a curiosity nano board - consider using it as a debugger (it requires to cut the UPDI trace on the back side at the Target/Debugger silkscreen, it is still possible to reconnect it through a solder bridge).
However, there might be a problem with the SPI Clock, as it is too high. According to the datasheet, the Maximum SPI SCK is 10 MHz. Consider clocking it down (8MHz).
If you have trouble with the speed - the SPI is double buffered, you can improve the SRAM write speeds by that. Then you can use VPORTB.OUT to set CS in a single Cycle.
I might try to debug it. Sorry if im going all over the place with the documenting of the problems that occur, they are really unpredictable. Right now i notice that each time it faults it gets worse and worse each time usually reprogramming it, it helps it a little bit. But now i notice by watching the power consumption and hearing the dac click, that it reboots constantly.
Measured the VCC lines of the board in all the places with the scope @ 100mv/div, no noticable power issues, it draws max 10ma.
Keep in mind that this same code works ok on a board with different layout and with minor changes in pin wiring, no problems with the sram there. Now it even stopped booting at all, ill just replace the MCU and post after that.