Sudden Change in Yocto Behavior During Firmware Debugging

Discuss use it and firmware update

Sudden Change in Yocto Behavior During Firmware Debugging

Postby helectromagneticus » Sep 30th, '17, 21:19

Hello kind people!

I've been working on code to correct the "pushing multiple step buttons during edit mode does weird things" bug, and I think I've fixed it. However, I've run into a bit of a snag. This morning when I turned the Yocto on via the standard 15VAC power inlet to triple-check my work, I noticed three problems emerge:
  • All of my programmed patterns were overwritten with a hit on every step for every instrument
  • Changed to patterns were not being saved
  • The Yocto was not responding to the tempo encoder or to external tempo sync (STOP/START via MIDI does still work)

These are all new behaviors that emerged without me changing the Yocto's code. Uploading the original 1.0c firmware via SPI doesn't correct this, nor does replacing the EEPROM chip. Do you any of you smart folks have any idea what may have happened here? I wonder if powering the Yocto via AC damaged the MCU. Perhaps quickly changing from powering the MCU with my programmer and then booting it via the standard power inlet caused some voltage spike that damaged the chip? There is a note in the build tutorial which warns that the analog and digital sections do not share a ground...

I have a few spare ATMEGA1284 and ATMEGA1284P chips on order already to see if swapping them helps.

Lastly, is anyone using an ATMEGA1284 as their Yocto MCU, or does everyone have the ATMEGA1284P? The Yocto install guide and kit BOM shows the P version of the chip, but my unit is the non-P version. Maybe this has something to due with this problem? The datasheets of these two parts are very similar, but the P version looks like it can be run in a lower-power state by shutting down some parts of itself.
User avatar
helectromagneticus
 
Posts: 71
Joined: Oct 26th, '16, 02:55

Re: Sudden Change in Yocto Behavior During Firmware Debuggin

Postby helectromagneticus » Oct 5th, '17, 05:34

Some updates:
  • I had plugged in a SPI EEPROM in place of the I2C EEPROM during a period of experimentation. Replacing this with the correct I2C EEPROM got me some functionality back. Drugs are bad, kids.
  • Despite this, the CB, CY, OH, CH, TR1, TR2, and TR3 are always hitting every step for every pattern. I can edit these hits out, but they always come back after switching patterns.
  • The remaining instruments work as normal - patterns can be saved just fine.
  • Pattern length and scale changes work as normal.
  • Tempo adjustments work as normal.

This looks like an I2C communications problem as far as I can tell. I probed the I2C lines and found that the first 8 instruments worth of steps for a given pattern are loaded from the EEPROM in a single 32 byte sequential read. The ATMEGA NAKs on the last byte and the comms stop. The ATMEGA then sets up another read (probably for another 32 bytes and the rest of the pattern data), but doesn't ACK any of the transmissions after clocking the first one in. Not seeing an ACK, the EEPROM just stops and waits as expected.

Sending data to the EEPROM works in the similar way, with two 32 byte transmissions for the entirety of the pattern data (the first transmission is for the first 8 instruments worth of step data, and the second is for the remainder). There are a couple other transmissions for scale and step length data, too. As far as I can tell, writing to the EEPROM is working.

I wanted to dig a bit deeper, so I "installed" the latest Arduino Wire library to get access to the Wire.available() function...
Code: Select all
oid Load_Pattern()
{
  unsigned int adress = OFFSET_PATTERN + pattern_nbr * PTRN_SIZE_BYTE;
  Wire_Begin_TX(adress);//commence la transmission a l'adress du pattern selectionner
  Wire.endTransmission();
  Wire.requestFrom(0x50,PTRN_SIZE_BYTE); //request des 64octets du pattern a l'adresse de l'eeprom
  for (char i =0;i<NBR_INST;i++){//loop autant de fois que d'instruments
    for (char j=0;j<2;j++){//loop deux fois pour les deux parti du pattern 1a16 et 17 a 32
      Serial.println(Wire.available());
      pattern[!pattern_buffer][i][j]=((Wire.read() << 0) & 0xFF) + ((Wire.read() << 8) & 0xFF00);//on load le pattern dans l'autre parti du buffer
    }
  }


Lo and behold, the first time Wire.available() gets called, my Yocto prints "32" out on the serial line. So even though Wire.requestFROM(0x50, PTRN_SIZE_BYTE); asks for 64 bytes (PTRN_SIZE_BYTE = 64), only 32 bytes are waiting in the buffer. How could this be? More digging will tell. If anyone has any suggestions, I'm all ears.

At least I fixed the pattern edit multi-button push bug...
User avatar
helectromagneticus
 
Posts: 71
Joined: Oct 26th, '16, 02:55

Re: Sudden Change in Yocto Behavior During Firmware Debuggin

Postby helectromagneticus » Oct 5th, '17, 05:47

Oh wow, I am an idiot.
e-licktronic wrote:Dear Diyer,

Here are the Yocto Arduino code and libraries.
Yocto_2_0.rar

Library.rar

You need to use Arduino IDE and change buffer length in Wire library to 128 (in the both file twi.h and wire.h)

You can use a USB to serial interface connected to program the Atmega 1284p with Maniac bug bootloader

Best regards,
e-licktronic

Emphasis mine. Thanks all, have a good night!
User avatar
helectromagneticus
 
Posts: 71
Joined: Oct 26th, '16, 02:55


Return to Yocto v1.0 Software

Who is online

Users browsing this forum: No registered users and 2 guests