analogRead() Hangs

[btribley]

I am coding in Atmel Studio 7 with DxCore board AVR128DA28 using the VMicro extension so I can debug with Visual Studio native tools. The top-level module is an .ino module so it is a sketch. However, all my code is in .h/.cpp files, it's ported from a project I did in PIC and ran out of RAM.

I am able to write to bits, use i2c and use the hardware serial port Serial2 to output to the usual PF0/PF1 serial pins just by doing the Arduino thing: Serial2.begin(9600) then Serial2.print/println, so the DxCore board code is there and working.

Integrating the rest of my application, the ADC hangs, apparently waiting for completion:

/ Wait for result ready / while(!(ADC0.INTFLAGS & ADC_RESRDY_bm));

So either the ADC hasn't been kicked off or its interrupt hasn't been set. Looking into it now.

In my old code before moving to the Arduino/DxCore infrastructure I never used interrupts with the ADC because I need the value and have to wait for it anyway.

I haven't done anything special to initialize the ADC. Depending on the DxCore code to set it up. Perhaps that is where the issue is.

Any suggestions appreciated.

Best regards, Bill

[SpenceKonde]

Thanks, will investigate. I have barely used the adc - it's probably something to do with the workaround for the silicon bug.

---

Spence Konde Azzy’S Electronics

New products! Check them out at tindie.com/stores/DrAzzy GitHub: github.com/SpenceKonde ATTinyCore: Arduino support for almost every ATTiny microcontroller Contact: spencekonde@gmail.com

On Sun, Jan 31, 2021, 09:45 btribley notifications@github.com wrote:

I am coding in Atmel Studio 7 with DxCore board AVR128DA28 using the VMicro extension so I can debug with Visual Studio native tools. The top-level module is an .ino module so it is a sketch. However, all my code is in .h/.cpp files, it's ported from a project I did in PIC and ran out of RAM.

I am able to write to bits, use i2c and use the hardware serial port Serial2 to output to the usual PF0/PF1 serial pins just by doing the Arduino thing: Serial2.begin(9600) then Serial2.print/println, so the DxCore board code is there and working.

Integrating the rest of my application, the ADC hangs, apparently waiting for completion:

/ Wait for result ready / while(!(ADC0.INTFLAGS & ADC_RESRDY_bm));

So either the ADC hasn't been kicked off or its interrupt hasn't been set. Looking into it now.

In my old code before moving to the Arduino/DxCore infrastructure I never used interrupts with the ADC because I need the value and have to wait for it anyway.

I haven't done anything special to initialize the ADC. Depending on the DxCore code to set it up. Perhaps that is where the issue is.

Any suggestions appreciated.

Best regards, Bill

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/SpenceKonde/DxCore/issues/63, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABTXEW5P54PGJCU2HZLNTFLS4VUIHANCNFSM4W3NHJ3A .

[btribley]

Wow, that was fast. I'm poking around too although I'm not able to go silicon-bug deep!

[btribley]

Found some undefined symbols ADC_MUXPOS_gp, ADC_STCONV_bm and ADC_RESRDY_bm in file wiring_analog.c line 100ff:

 /* Select channel */
  ADC0.MUXPOS = (pin << ADC_MUXPOS_gp);

  /* Start conversion */
  ADC0.COMMAND = ADC_STCONV_bm;

  /* Wait for result ready */
  while(!(ADC0.INTFLAGS & ADC_RESRDY_bm));

I did a search for ADC_MUXPOS_gp starting from DxCore-master (top of DxCore tree off github) including subdirectories for in files .c .h .cpp .hpp and found no entry besides the one in wiring_analog.c

Next step is to try to figure out where they are. Found them here: C:\Program Files (x86)\Arduino\hardware\tools\avr\avr\include\avr\ioavr128da28.h Apparently when DxCore is selected as the board this file is not also included.

[SpenceKonde]

The appropriate io*.h headers are always included. io.h is what actually pulls in the proper header (it also grabs sfr_defs.h and xmega.h (based on what things don't need a #include to use)) - the -mmcu compiler parameter is transformed into a define that specifies the part, which io.h looks at and then includes the part specific one for that mcu.

[btribley]

So there is an issue with how VisualMicro is using DxCore boards. Late yesterday the hardware debugger stopped working, some kind of Atmel Studio/Visual Studio issue with VisualMicro. I finally got a forum registration, today I will post there about these issues. How are you developing with DxCore? Eclipse? Arduino IDE (doubtful)? Do you have hardware debug capability? Thanks for your help, Bill

[SpenceKonde]

Arduino IDE (lol) All of the actual editing is done in sublime. And maybe 6-8 Arduino installations that I've mangled in various ways; the main one (which has never had any packages installed through board manager except micronucleus to get the micronucleus upload tool in), several portable ones, and two copies of the 1.0.6 IDE (for the build tools) but with avr-gcc itself updated, for building the bootloaders. I'm not sure I need two (one has 5.4, which I use for ATTinyCore's bootloaders. the other has 7.3 for the modern ones),

I have never cared for "Debuggers" - not hardware ones, not software ones (for applications running on desktop computers). Too much of ones effort goes towards working with the debugger instead of actually fixing the bug, I rarely find myself encountering cases where I wish I had a hardware debugger - usually there's some way to get the information I need out via other means.

In the case of the ADC issue... well what could possibly be wrong? Say, what's ADC0.CTRLA when we started? That's about the only way that this could be broken such that it straight up hung, since the actual analogRead() code never gets touched (it's a pretty vapid routine)., and the last time I did touch it, someone tested it immediately after and said thanks. On the other hand, I know I was reorganizing the initialization code shortly before release. Sure enough, at start of setup(), ADC0.CTRLA is 0x00. Because I moved the ADC initialization into init_ADC0(), but never call that. If init_ADC0() is declared, you can call that from setup() in released version and it will fix the ADC.

This, of course, is the kind of thing that all the CI compile-testing in the world can't catch, because it builds just fine.

What one wants (and what they do) is to have physical hardware that can get automated tests run - but there's only so much time that I have, and there's a non-trivial amount of tooling there, not to mention hardware...

[btribley]

Thank you for taking the time to explain. This gives me something to look for. I have been writing software since the 1970s and have never had problems getting debuggers to work. They are a godsend for strange stuff like this: step till it breaks! I will try dumping my application into the Arduino IDE and just running it. I have progressed from Arduino IDE to Eclipse to Atmel Studio 7 to Visual Studio 2019 Community testing the i2c, never dreamed I would have ADC problems. More later!

[btribley]

I put the test for ADC0 in the startup section of a very simple sketch that reads temperature and flashes a LED. Temp data changes when I put my finger on the chip then it slowly goes back through the original value so the sketch works. Regarding AC0.CTRLA, it's zero: Output->

My Name Is Sue How Do You Do?                                              
ADC0.CTRLA: 0
Temperature: .ˆ. deg                                                  
Temperature: .ˆ. deg                                                  
Temperature: .ˆ. deg                                                    
Temperature: .ˆ. deg

Sketch run in Arduino IDE:

#include <DxCore.h>
#include <UART.h>
#include <Wire.h>

  #define IND02 PIN_PC1
  #define I2C_ON PIN_PA6
  #define BT_EN  PIN_PA7

  #define CMD_MODE 0xfe
  #define DISPLAY_I2C_ADDR 0x72
  #define PWR_ON 0x41
  #define PWR_OFF 0x21

  #define tempSenseWriteAddr 0x49   //0x92 is write address;

void setup() {
  pinMode(IND02, OUTPUT);
  pinMode(I2C_ON,OUTPUT);
  pinMode(BT_EN,OUTPUT);
  digitalWrite(I2C_ON,HIGH);
  digitalWrite(BT_EN,HIGH);
  Serial2.begin(9600);
  delay(500);
  Wire.begin(); // join i2c bus (address optional for master)
  Serial2.println("My Name Is Sue How Do You Do?");
  Serial2.print("ADC0.CTRLA: ");
  Serial2.println(ADC0.CTRLA,HEX);

  Wire.beginTransmission(tempSenseWriteAddr);
  Wire.write(0); //temperature register
  Wire.endTransmission(true);

}

byte x = 0;
bool onState = true;

void loop() {
  digitalWrite(IND02,onState);
  onState=!onState;
  Serial2.print("Temperature: ");
  Wire.requestFrom(tempSenseWriteAddr, 2);    
  while (Wire.available()) { // slave may send less than requested
    char c = Wire.read(); // receive a byte as character
    Serial2.print(c);         // print the character
    Serial2.print('.');
  }
  Serial2.println(" deg");
  x++;
  delay(500);
}

[btribley]

If I could bother you with a question: Where in the Arduino source tree are the board settings shown in this image saved? I got the debugger working in Atmel Studio 7 by uninstalling VisualMicro. I think VisualMicro is a gimmick and not worth using let alone paying for. Beginning to see that I should be able to use Arduino IDE to configure everything then compile/run in Atmel Studio, or if I know where the settings are just put them in manually.

I have three tools installed: Atmel IDE, Visual Studio Community and Atmel Studio 7. All of them see the same Arduino setup if VisualMicro is installed, so the settings must be in a location common to all, independent of any "project" or "solution" files. Thanks in advance for any insights.

[SpenceKonde]

That would be in your Arduino IDE's preferences.txt. You'll probably be horrified when you see how they are stored! Honestly, I kind of was too, and it was a bit of a heads-up that I really ought to put a bit more thought into how I handle that sort of option between my cores!

[btribley]

Yes, it's pretty bad. So does the Arduino IDE automatically create #defines from this file or is preferences.txt somehow loaded by the compiler at build time? In other words, how do these settings get from here to the avr-gcc compiler when a sketch is built?

Answer: preferences.txt is a reflection of the state of IDE internal variables. It's saved when exiting the IDE. Apparently any tool that selects the board will see the internal configuration. I am going to delve into that a bit, because at this point it's the only thing I can't do directly from Atmel Studio 7 that I can do within Arduino IDE.

[btribley]

Let me know if you would like me to test anything. I have a AVR128DA28 set up and ready to go.

[SpenceKonde]

At this point it's clear what needs to be done - the only reason there's no fix yet is that I found a bunch of other broken things while I was looking around there. There are certain settings you can pick that will make the millis timekeeping to wacky stuff. Either that or you can get PWM frequencies out that are outside of our specified acceptable analogWrite() frequency range.

[btribley]

No worries, I am not in a rush. Would rather you take the time to get it as good as you can. I appreciate your time spent, on my own I couldn't do it. Having this core to support individual AVR128DX parts that can be used in custom PCBs is really great. Let me know if you want me to test anything.

[SpenceKonde]

Thanks! Should be fixed in github version!