AVR Freaks

Hi!

Thank You for the reply!

I don't know currently what the exact cause of this failure. The support team got my modified USB Device CDC example, they must be checking it nowadays.

The bad news is that I need the cache. Without it my project won't work any well. Though, I need SDRAM and USB "mass usage" too so it doesnt really matter why I can't continue my project. I just can't.

Memory corruptions isn't because of some cache maintenence missing? Unfortunately I have fixed some of this kind of bugs in the examples when I was getting familiar to the microcontroller. Sometimes the compiler made mistake and some const arrays were shifted in the memory... You can never know. The best to aviod these is using assembly.  I love assembly but this project is too complex to be written in asm.

Furthermore, AS7 sometimes shows weird data in Memory or Watch windows. I don't know why... it's random. But I have tried to use the scrambling function of the SDRAM controller (to have quasi random data line changes) and with it AS7 was showing even more weird data (at SDRAM) and I was unable to edit them so that other bytes won't change... Scrambling should be absolutely transparent, for the debug interface too.

Please tell if something new happens with your project.

Bests,
Zoltan

Hi!

Just for platform test, could you try to turn off cache in you project?

I don't remember exactly, but I think I have tried it. Don't even remember the result.  I'll try it again, on both the boards (mine and the Xplained Ultra).

Did you check addresses in the *.map-file? compiler places any named entity description there. Just search the name in any text editor in the file.

From the start of the .lss file it was clear that all VMA and LMA address pairs were shifted with 4 bytes. I used SRAM compilation. This way the relocate segment was badly copied. I tried things to overcome it but nothing helped. Then, updating the AS7 (for some other reason) make it disappear. Though, I have tried using arm-eabi 5.2.1 earlier, but didn't solve it either.

Fortunately, it's not a case with the SAM chips. 

Currently, my SDRAM issue is being inspected by the support team. I have sent a simply modified version of USB CDC example that shows the issue on the Xplained Ultra board. I am waiting for the result.

Until then, I am working on an other project, but I'll check the cache thing soon again.

Hi!

Now I am doing the tests. I use the Xplained board. It does the following: enumerates the Camera (on USB host) and starts reading frames into SDRAM (DMA).

The results:

1) Compiled in debug mode, no optimization applied to the code (regardless if I use cache or not):

• Works with clock settings (HCK, MCK): 75/75, 150/75, 150/150, 246/123
• Fails: 300/150 (a fault is done and handled)

2,a) The same but I do write to the SDRAM meanwhile (very much, toggling data bits), cache is turned on:

• All "low clock" settings make the USB fail as "normally"
• 300/150 does the same, plus if the SDRAM writes come some later than the first frame has begun to be transmitted, the CPU does a fault.

2,b) The same without cache:

• ALL settings do the USB fail but NO CPU FAULT even at 300/150!

The failure is something weird... while the pixels are coming to SDRAM, the CPU/SRAM seems to do something wrong, it calls a function with invalid address ("never execute" region) or a usage/hardfault executing some other 'data'... It looks like the CPU/registers are messed up inside...

So, turning off the cache eliminates the CPU fault at the fastest speed but the USB thing remains. It's rather hard to understand why it is not eliminated when I do not write to the SDRAM additionally...

Summarized: 

There are two type of "faults" here:

• "USB", when the USB host losts communication with the device. (This is the main fault we are searching a clue for.)
• "CPU" fault, when the CPU looks like working wrong and some kind of CPU fault will be thrown.

The compilation/hardware configurations are:

• clock speeds: fast ("300/150" MHz) and "slow"
• using cache (I+D) "+" or not "-"
• with ("+") or without ("-") writing additionally to the SDRAM (while the camera is streaming data to the SDRAM)

The result table:

Well, that's enough for now. I'm gonna share this with the support team as well.

Have a nice day!

I suspect the same, maybe we are facing the same trouble (cause) but different exact issues.

The support case is still open and "hanging". My demo example for Xultra board is sent in for over a month now but still no feedback if it's working or not. Two things can happen: 1, there is a huge problem about the SAM series and they are figuring out what to do; 2, my contact is too slow.  I would need a result now, the project would be not only a hobby one. Though, I had time to work on another project that may partly "replace" this one but the invested work into the suspended one may go to /dev/null.

Rather weird things happen recently about this issue.

Today I've made tests with the EBI data pins, disconnecting each from the SDRAMC peripheral, so less pins are driven, less coupling to the other signals/powers. The result is interesting. The data lines that affect the "CPU fault" are located next to or close to the VDDOUT and VDDIN power pins. So I made a simple (not the best) external 1.25V supply and disconnected the board from the VDDOUT pin. The CPU fault disappeared and the USB issue stayed.

So I thought that the power pins may be the solutions. (As at the very beginning but have found nothing.) I started playing with stronger HF filters, bigger capacitors at the VDDUTMIC power pin (that may affect the USB) but nothing changed. Meanwhile I've found a way to do the CPU fault again...!  I've disconnected the !SDWE pin, no CPU fault occurs if the pin is driven low or high constantly. But I've made a mistake for first and set another PIO's registers and I only disabled the peripheral driving of the pin, but haven't set it to be an output. As an input, it must be coupled with many surrounding lines and it must be toggling continuously. This leaded to the same CPU fault...

I'm totally lost on these power and line coupling issues. And the USB is still unusable.

The support team said that the modified example that fails at my board works stable at them. So what now. I own an unstable demo board and a more stable but still bad own one. What's the next step...? This takes up too much time and nothing is better. No solution, not even a good tip.

Meanwhile I am working with an AVR to test some pre-prototype things. At least they work well. But I would need this damn massive SDRAM-usage later with a strong CPU. May separated power supplies for SDRAM and MCU solve the issues? (My last idea.) I could hack my board (for the Nth time yet) like this but can't do it on the Xplained Ultra. Ahh....

I meant that I configure the !SDWE pin (PD29, for example) as output, driven by the PIO registers, not one of the available peripherals (A to D). Meanwhile, the SDRAM controller is configured and working, so it drives all the other pins.

Of course I did not disconnect any power pin. :) Except that I have to desolder the VDDOUT (internal regulator) pin to apply an external 1.25V for the core, utmi etc. This new power source made the CPU fault disappear...

...temporarily, since I've found some way to have it again, but this requires another "configuration"... Damn. So, the system stability depends on the 1.25V source, at least a bit. I am testing with this power supply now, rather interesting results I had.

One result is that I can not interpret at all: if I configure the SDCK pin as a PIO output to low, one should think that the SDRAM IC will not function (store, give data) but the SDRAM controller inside the MCU will. It DOES NOT!!! If the pin is an output 0, all the data pins (D0..D15) are not driven as well. What...??? How the SDRAM controller depends on the pin's configuration? It's a simple multiplexing at the PIO whether the peripheral or the PIO registers set the data/direction of it. And of course as the data pins are not toggling, the system is stable and no errors occur. If I let the SDCK pin driven by the SDRAM controller, the USB fault is present, the communication through CDC dies.

The tests about these pins (all of the SDRAM controllers) was to discover any correlation between the driven lines on the PCB and the fault(s). And there is! The less data/address lines are toggling on the PCB (and between the chip die and the case's pin), the less probably that the USB communication will fail. Doing these tests I have faced the above "issue"... that is nonsense.

It's way too annoying now, why a factory PCB (or MCU) doesn't work any stable. Showing many issues I have to figure out myself. Even my own PCB is a lot more stable, that's why the USB failure was totally hidden until I started to use the SDRAM very hard. (This was the goal, to have a MCU that can handle such hard processings.) 

Atmel has received my results, the description of the used system, everything. I've made a modified USB CDC example to show them the faults. It works at their test setup but on mine. That's all they could discover until now.

I suspect a very strong problem about the chip. It's an early one (the V71), marked as -ES3 (must be engineering sample). But at least if I knew that the board is "faulty" and they could replace it or just ensure that is has problems and I should use newer chip versions.

In my project a S70 type MCU is used. This shows the same USB faults with less probability but no CPU faults at all. That IC is not marked really identifiable, I don't know what series it may be. The only thing I know about it is that it may be a very early one. I've ordered it when it was not yet available at the distributor (Mouser). I don't need Ethernet and such function that the V71/E70 has.

A real solution were if Atmel would tell me to use a new chip (or E70 for example) because it is fixed and seems stable by all the users. (No such faults observed.) The only reason why I can wait some more for the solution is that there is many new things to develop before I would need the "ARM with SDRAM" unit again. :) I am doing those controlled with AVR. I love AVRs. And I would love SAM series too, for today I've got quite familiar with them. CM7 core is very effective and it's fun to write speed optimized assembly routines on it. ;)

Hi!

The PLLs may be a little bit more vulnerable than they should be, as they are a part of the clock system. Just like the internal crystal oscillator circuit that is proven to be a bit weak.

I would advise to route the PLL clock diveded to an IO pin for both the 300 and 600 MHz PLL settings and monitor it with an oscilloscope using a min-max (envelope) mode. If the peak-to-peak jitter at 300 Mhz was considerably higher this would explain this behaviour. It's enough to have the SDCK to be a bit faster for only one clock period to have issues.

Such measures has proven my issues with the USB (PLL). I've attached my screenshots from the UPLL divided by 16 signal when the system was idle (CPU was doing NOPs in infinite loop) and when I was using (writing) the SDRAM quite hard. Similar but lower differences may be osberved for the PLLA clock for 300 and 600 MHz clock speeds.

Bests,

Zoltan

Edit: sorry, these are frqencies UPLL divided by 8.  Though it doesn't really matter.