View previous topic :: View next topic |
Author |
Message |
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Mon Aug 29, 2016 10:35 pm Post subject: Mega2561 strange problem ONLY on Port A.6 |
|
|
I use part of Port A as logic inputs in my project and have noticed a peculiar problem on only one pin:
Code: |
$regfile = "m2561def.dat"
$crystal = 16000000
$hwstack = 400
$swstack = 550
$framesize = 345
$Baud = 9600
UCSR0A.U2X = 0
DDRA = &B1000_0011
PortA.2 = 1 : PortA.3 = 1 : PortA.4 = 1 : PortA.5 = 1 : PortA.6 = 1
|
For some reason, grounding PortA.6 results in a massive increase in current draw (upwards of 100 ma) but no other pins respond this way. I have noticed this all 2561's I've tried (at least 3) and even on the M128. I can find nothing in the ERRATA for either AVR. The only way to prevent it is to turn off the internal pullup on A.6
Thoughts?
(BASCOM-AVR version : 2.0.7.9 , Latest : 2.0.7.8 ) |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Tue Aug 30, 2016 6:32 pm Post subject: Re: Mega2561 strange problem ONLY on Port A.6 |
|
|
KenHorse wrote: | For some reason, grounding PortA.6 results in a massive increase in current draw (upwards of 100 ma) but no other pins respond this way. |
You have a hardware problem somewhere, short-circuit to another pin, a.s.o., as the software is not the culprit.
Ah, yes, beside in case the shown is your actual code, it misses an End, without the µC may run in an unknown condition.
Quote: | I have noticed this all 2561's I've tried (at least 3) and even on the M128. |
As the M2561 and M128 aren't pin-compatible, I do not have to ask if the same PCB was used. I'd try different designed PCBs anyway. |
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Tue Aug 30, 2016 6:34 pm Post subject: Re: Mega2561 strange problem ONLY on Port A.6 |
|
|
MWS wrote: | KenHorse wrote: | For some reason, grounding PortA.6 results in a massive increase in current draw (upwards of 100 ma) but no other pins respond this way. |
You have a hardware problem somewhere, short-circuit to another pin, a.s.o., as the software is not the culprit.
Ah, yes, beside in case the shown is your actual code, it misses an End, without the µC may run in an unknown condition.
Quote: | I have noticed this all 2561's I've tried (at least 3) and even on the M128. |
As the M2561 and M128 aren't pin-compatible, I do not have to ask if the same PCB was used. I'd try different designed PCBs anyway. |
I only posted the relevant section of my code as the total program is several thousand lines.
As for the pin compatibility, indeed they ARE the same (you're thinking the 2560 perhaps?) |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Tue Aug 30, 2016 6:40 pm Post subject: |
|
|
Yes, checked the wrong pinout. |
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Tue Aug 30, 2016 6:50 pm Post subject: |
|
|
MWS wrote: | Yes, checked the wrong pinout. |
It happens!
I just checked my pc layout (done with Cadsoft Eagle) and that pin goes only where it should (and I checked for unintended shorts and there are none).
The M128 I used before I changed out to the 2561 behaved exactly the same way. I'll be darned if I can figure it out!
(perhaps running this through AVR Freaks might be better as perhaps this isn't a Bascom issue (but it might be the way the code is compiled!) |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Tue Aug 30, 2016 7:27 pm Post subject: |
|
|
KenHorse wrote: | (but it might be the way the code is compiled!) |
How do I have to understand this?
The result of the compilation is assembler code, which can be run through AVR Studio, that's what I did.
At the end of the code one checks what registers are set, if the extended memory controller isn't switched on in this case. Saw no problems.
Does the actual shown and compiled code is liable for the problem, or is it only an excerpt to be posted here?
These processors have compatibility fuses, afair these are switched on by default, did you check this? |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Tue Aug 30, 2016 9:06 pm Post subject: |
|
|
you do not really think that there is code in bascom that would treat pin 6 different than other pins, right?
if you are sure that your hardware is 100% ok, the cause is inside the processor.
I advise to write to atmel support. that there is no errata yet does not mean much. _________________ Mark |
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Tue Aug 30, 2016 11:38 pm Post subject: |
|
|
Well Mark... I wasn't picking on Bascom
I was just wondering aloud as there was no errata regarding this issue from Atmel and as the issue was observable on several different AVRs, process of elimination and all that...
I am taking this to Atmel at this point and appreciate the comments (from everyone). |
|
Back to top |
|
|
MWS
Joined: 22 Aug 2009 Posts: 2262
|
Posted: Wed Aug 31, 2016 6:34 am Post subject: |
|
|
It's a bit unsatisfying not to get response, if one tries to point out potential issues:
MWS wrote: | Does the actual shown and compiled code is liable for the problem, or is it only an excerpt to be posted here?
These processors have compatibility fuses, afair these are switched on by default, did you check this? |
|
|
Back to top |
|
|
KenHorse
Joined: 16 Jul 2004 Posts: 523
|
Posted: Wed Aug 31, 2016 4:14 pm Post subject: |
|
|
MWS wrote: | It's a bit unsatisfying not to get response, if one tries to point out potential issues:
MWS wrote: | Does the actual shown and compiled code is liable for the problem, or is it only an excerpt to be posted here?
These processors have compatibility fuses, afair these are switched on by default, did you check this? |
|
I have checked the fusebits and they appear to be correct as all other aspects of using the M2561 in my application work properly so I took Mark's comments to heart and will follow up with Atmel. I do appreciate your suggestions very much |
|
Back to top |
|
|
|