Xmega Bootloader Shenanigans (Solved)

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks to Sukuwc for posting the zipfile for app note AVR42788 !!  As a result, I was able to get a XMEGA bootloader running from SD card on my telescope controller project.

 

However, I discovered that one of three of my prototype controllers is temperamental. If I leave it off for an hour, and plug it in and bootload, it will work perfect every time. Right then it can also be programmed again and again for a little while -- but once it "warms up" though, it starts getting FAT read errors, eventually to the point it will not be able to succeed ever. Until I unplug it and walk away for a while.

 

My other 2 controllers work perfectly every time.

 

So the only components involved are the uC and the SD card, some pullup resistors, and some very small series resistors. I reflowed every joint between them, but it didn't change anything.

 

I swapped SD cards around and even brands and sizes, but it didn't change anything.

 

Can this really be the uC acting bizarrely? I am kinda loathe to go and replace the 64 pin uC.

 

How much capacitance should I have on the SD power? I have a 10uF and a 0.1 uF. I am guessing that should be more like 47uF or more? 

 

Thanks for your help

Mike in Alaska

Last Edited: Tue. Apr 3, 2018 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the clock source to these three controllers?

Could it be the "bad" one is not running at the speed you expect and drifts as it "warms up"?

David (aka frog_jr)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Congratulations on your successful XMEGA SD bootloader effort!

deathcow wrote:
Can this really be the uC acting bizarrely?
Yes

Digital logic is dependent on solid power and solid clock.

XMEGA can upset voltage regulators (most regulators are conditionally stable); SD card's maximum current is approximately an order of magnitude greater than an XMEGA.

XMEGA can output clkPER.

Some DSO can create an eye diagram of a clock (assuming the scope's phase noise, vertical amplifier noise, and ADC noise are low enough)

A clock's phase noise and amplitude noise can be measured.

A regulator's efficiency, noise, and stability can be measured.

If a voltage regulator is or could be an issue then substitute it for a cell or battery (unconditionally stable; add some bulk surge-rated tantalum or electrolytic capacitance due to cell or battery's inductance and cabling)

RC oscillators will have significant phase noise due to ground current impulses under the MCU (XMEGA have excellent dtCK)

If the internal clock is an issue then substitute with a low phase noise external clock.

EMC, ESD, EFT, and lightning could be issues that affect regulators and/or clocks (a common EMI souce is a cellular phone or modem)

deathcow wrote:
How much capacitance should I have on the SD power?
Depends on the voltage regulator's gain margin (a measure of stability)

Consider also how much inductance to have on power (XMEGA schematic checklist)

 

P.S.

deathcow wrote:
Mike in Alaska
A beauty of Alaska is greatly reduced light pollution though "too" cold.

Flash has a temperature limit; might consider industrial SD flash, or, industrial FRAM or MRAM if storage is approx 1MB, or, Bluetooth 4 to the operator's smartphone that's inside their interior coat pocket (phone warmed by their body's heat)

Alaska is COLD to this Texan.

A fellow Texan recounted the serious Arctic weather and exposure safety training he underwent before working in central Alaska.

 


XMega SRAM slow turnaround? - Solved (Glitchy Power Supply).

by AtomicZombie

...

https://www.avrfreaks.net/forum/xmega-sram-slow-turnaround-solved-glitchy-power-supply#comment-1028546

EDN

Testing a power supply – Stability (Part 3)

by 

April 17, 2013

https://www.edn.com/design/power-management/4412230/1/Testing-a-power-supply---Stability--Part-three-

Microchip Technology Inc

Microchip Technology

Application Notes

AN_8278 AVR1012: XMEGA A Schematic Checklist

http://www.microchip.com//wwwAppNotes/AppNotes.aspx?appnote=en591787

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> What is the clock source to these three controllers?

 

I am not really sure. I know how my own clock stuff works, its just a few lines of code. But in these generic app note modules the clock setup and selection code just goes on and on and on.

 

Now, why could that be a problem for only 1 if they are running the same software?

 

 

Last Edited: Mon. Apr 2, 2018 - 07:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lots of good advice above.

 

I might also add:

 

If a board works well when first powered up, and then gets erratic after it warms up, perhaps the power supply voltage regulator is over-heating and going into thermal shut-down/rollback mode?

Do you have a Scope on the power supply when the board misbehaves?

Is the power supply stable, or dropping, out, or worse yet, oscillating?

 

I assume AVcc is connected to Vcc?

I assume you have ALL Vcc and Ground pins connected to the rails?

I assume you have a 0.1 uF by-pass cap across each Vcc/Ground, and the AVcc/Ground pairs of pins, and that they are mounted very close to the physical pins on the micro?

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi JC

 

Yes on all the questions about proper connections to rails, caps, Avcc, bypass caps. I will take a close look at the power supply over time. 

 

I built 4 prototypes of my telescope controller during this round.

Two of them - Bootload just fine, work every time.
One of them (the one I am whining about) - Doing the "Bootloads perfect until powered up for a while."

So yesterday I took that bad one and replaced the CPU to see what happens. This time it wouldn't even ever get past this inner check:
 

		do {
			status = sd_mmc_test_unit_ready(0);
			if (CTRL_FAIL == status) {
				while (CTRL_NO_PRESENT != sd_mmc_check(0)) {
				}
			}

		} while (CTRL_GOOD != status);

 

So I tested my 4th controller and it does the same thing, it cant get past that same sd_mmc_check.

 

Same circuits. Same software.

 

My own SD card init, reading and usage has worked perfect on all four.

The AVR app note code is not being so lucky.

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the posted picture, the one on the right is missing two parts, to small to see what they are....

 

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

> the one on the right is missing two parts,

Those are the i2c RAM i ditched when I got the SD card. I kept one.

 

I have all four controllers working great now. While I had correctly repointed all the SPI I/O lines to the desired port on the XMEGA, I had not repointed the card detect line. I have no card detect on my slot. 

 

What's comic is it was it was pointed at, and how that caused my grief. It was pointed at my GPS systems position lock indicator. So, on my first controller, which sat on the bench with a GPS antenna attached, it would eventually get a GPS lock, and start indicating the SD card was no longer detected.

 

Since the next two controllers never got a GPS lock (no antenna) -- they always programmmed.

 

The fourth controller is waiting to have its GPS unit installed, so it acted differently, permanently indicating no SD card.

 

This explains why the ongoing programming would fail also, and seemingly at random points in it. The GPS lock would be OFF when the initial power was applied, allowing programming to start successfully. But before the programming could complete, it would regain lock and would lock up with the job incomplete.

 

When I realized what it was, I reached up and undid the GPS antenna on my "problematic" controller, and it programmed immediately.

 

 

 

 

 

 

 

Last Edited: Tue. Apr 3, 2018 - 08:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, what a great story!

 

It is always good to fine the definitive cause for a "bug" in the system.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No need to call Bruno then, with his USD 100.000 test equipment:

 

The Case of the Crashing 68000

http://www.ganssle.com/articles/ajake.htm

 

Bruno wrote:

"Dis ting is oscillating", Bruno roared. "What, yoose got amateurs designing dis stuff now? Watch - I triggered da scope on da read pulse. Look at the data line afterda read pulse goes away."

"No one does that," snapped the Kid. I didn't know what Bruno was getting at, but having seen him in a rage once before, I kept mum. I know for a fact that the pub owner now wishes he had too.

Bruno's neck started turning red. I backed slowly away...

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com