>At 18.12 2012.02.08, you wrote:
>>Thank you both, Mario and Alan.
>>
>>I checked errata for 30f4011 and discovered it has "lots" of "bugs", my
>>next micro will be a 33F or 33EP (I love 33EP256MU806 specs for a 64 pin
>>micro).
>>
>>It is not possible to do AD conversions at 1 Msps due to bugs, max is 750
>>ksps.
>>
>>After inspection of assembly output from my C compiler, I discovered it w=
as
>>setting SAMC and ADCS in ADCON3 register at its maximum values (SAMC=3D11=
111
>>"31 Tad" and ADCS=3D111111 "32 Tcy"). That was the reason of its slow spe=
ed.
>>Now, lowering this values I speeded it up a lot. I have to check for
>>integrity of data at that speed, but looks promissing and more acceptable=
..
>>
>>I still have a lot of doubts, but the increase of speed makes me happy an=
d
>>do not need to dig more into the question by the moment.
>>
>>Thanks again.
>
>You're welcome.
>
>I just stumbled upon another problem, but on a PIC32MX1XX: when I enabled
>compiler optimizations, the ADC results looked buggy. In the end, as I am
>using autosampling, I had to put at least a NOP or a DONE=3D0 between the =
line
>with SAMP=3D1 and the loop where I check if DONE became 1. I found the "bu=
g"
>as I had suspected in the past that this would be necessary, however the
>documentation didn't specify it was, so I omitted the extra code. Now I
>know it was due.. it happens very rarely that the loop get skipped as it
>finds DONE at 1 because of the previous conversion and SAMP=3D1 didn't cle=
ar
>it in time (however I am now going to disassemble it do see if it's the
>compiler that maybe reordered the instructions!), but as it was for a buck
>SMPS converter loop, it caused some visible (smoky) problems. :D
>
>Cheers,
>Mario

PS: no, the compiler is behaving correctly, it must be an hardware issue.

Specifically this looks like trouble:

      sw    a1,-28672(v1)   ; SAMP=3D1
loop: lw    v1,-28672(a2)   ; while (!AD1CON1bits.DONE);
      andi  v1,v1,0x1
      beq   v1,zero,loop

insert a nop between the first and second instructions, and the bug is gone=
..

I was aware of such issues only when writing '0' to the ON bit of a module,
in fact every time I disable a module, I add a nop. But I wasn't aware (and
the documentation would exclude it) that a store immediately followed by a
load from the same register would cause corruption, or maybe it's just the
ADC module that (sometimes!) doesn't have enough time to clear DONE after
SAMP is set.

Please note that PB=3D1 of course (peripheral bus clock is same as CPU cloc=
k).

In any case, that wasted 5 hours of my life.. and bughunting is not really
my favourite sport, but every such situation has something to teach.. and I
wanted to share this with you all ADC-weirdly-behaving frustrated fellows.

With kind regards,
Mario

--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.