Transfer data from 1 Dim array to 2 Dim array trouble. (embedded systems)

I need to make a boxcar average for analog to digital conversions. I cannot do this when one array won't copy into another.

Code:

---

    //DEBUG TEST
for(Channel = 0; Channel <= ADC1_NUM_OF_CHANNELS - 1;Channel++)
                    {
                        ADC1_Val[Channel][ADC1_DIM2Counter] = ADC1_DMA1C1_Base[Channel];
                    }

---

First data IS loaded correctly into ADC1_DMA1C1_Base, when I step through the for loop, the data is NOT transferred correctly to my 2 Dim array, any ideas why? Data is close but not correct. Off by anywhere for 2% to 50%. Sometimes the data is correct.

Each time the loop is executed, ADC1_DIM2Counter increments by 1, but I can't even get the loop to execute once without the numbers in both arrays being different. So the second dimension can essentially be ignored.

Both arrays are same size in terms of member size. (16 bits)

Any thoughts?

Is it possible you have your ADC1Val[][] indexes reversed?

Without seeing more code it's hard to tell what is wrong. What do you mean by "Each time the loop is executed, ADC1_DIM2Counter increments by 1", I don't see any loop that is modifying this counter.

Jim

Quote:

---

Originally Posted by Daniel.Blesener

Each time the loop is executed, ADC1_DIM2Counter increments by 1, but I can't even get the loop to execute once without the numbers in both arrays being different. So the second dimension can essentially be ignored.

---

Both arrays? You mean trying to write to ADC1_Val is also corrupting ADC1_DMA1C1_Base? Or maybe that the other dimension is being corrupted. Possibly it could by memory allocation problems -- maybe the memory was allocated in a way that doesn't match up with the expected layout for a 2 dim array. Or maybe you have just got the indices the wrong way around.

Might be worth checking the addresses of both sides of the assignment as you start to see corruption.

Other than that vague thought, it's a bit hard to help without much info. I'd like to see a bit more code -- it'd be helpful to see the declarations/definitions of both arrays, the expected dimensions.

Jim, this loop is in an interrupt. Each time the the proccessor completes ADC conversion for all 8 channels, the data is automatically stores in the array ADC1_DMA1C1_Base[]. For the first 100 interrupts, I need to store data in the 2 dimensional array from the ADC1_DMA1C1_Base[]. And no, the order is deffinately correct. I can see this in my watch window, the values are just incorrect.

Smokeyangel- ADC1_DMAC1_Base is CORRECT. No doubts about that. The tranfer to the other array is where the numbers are going wrong in my watchwindow.I was thiking that memory allocation was the problem but I am not sure how to fix that. I set up DMA and ADC to work all as 16 bit members with same size arrays. I will go through that again though.

I can send code if you want but it will not make sense because it is for a STM32F103ZET 32 bit proccessor using STM standard peripheral libraries, and would include thousands of lines to make the couple hundred lines which include the ADC and DMA which work with this interrupt make sense.

*The values "transferred" are just incorrect

Code:

---


#include <stdio.h>
#define ROWS 3
#define D2COLS 4
#define D1COLS 12


int main(void) {
  int oneD[D1COLS]={0,1,2,3,4,5,6,7,8,9,10,11};
  int twoD[ROWS][D2COLS];
  int i, r, c;

  for(r=0;r<ROWS;r++) {
      for(c=0;c<D2COLS;c++) {
        twoD[r][c] = oneD[r*ROWS+r+c];
      }
  }
  printf("The 1D array is:\n");
  for(i=0;i<D1COLS;i++)
      printf("%2d ",oneD[i]);
  printf("\n\n");
 
  printf("The 2D array is:\n");
  for(r=0;r<ROWS;r++) {
      for(c=0;c<D2COLS;c++) {
        printf("%2d ",twoD[r][c]);
      }
      printf("\n");
  }
  printf("\n\n");

  return 0;
}

---

Quote:

---

Originally Posted by Daniel.Blesener

I can send code if you want but it will not make sense because it is for a STM32F103ZET 32 bit proccessor using STM standard peripheral libraries, and would include thousands of lines to make the couple hundred lines which include the ADC and DMA which work with this interrupt make sense.

---

No, don't think there's any need to try to send piles of stuff. I'd just like to know about the types of ADC1_Val and ADC1_DMA1C1_Base. I guess that ADC1_DMA1C1_Base is a pointer to memory mapped data, so a uint16* ? . What about ADC1_Val? Was it originally declared as a multidimensional array? Is it also memory mapped to some specific address, or allocated on the heap or the stack or where? If it was allocated on the stack, was it on the right stack for you to be able to access it from an interrupt routine?

I'm afraid I don't know anything about ADC or DMA but I'm reasonably competent with ARM stuff - if you posted the disassembly of just that for loop it might be possible to spot a dodgy offset. Maybe.

If one of your arrays is being changed inside an interrupt routine, you should turn off this interrupt when you are copying this array to avoid problems with the interrupt changing the value mid copy. Remember it may take more than one instruction to copy any single value and if the interrupt happens between copying one of the bytes of your number you will likely get strange results.

Jim

smokeyangel - That makes sense. All the data I am working with is uint16. ADC1_DMA1_Base is not a pointer, it is just a variable I made. I used stm32 DMA library functions to redirect all converted ADC data to this array. Each time a conversion happens, it stores the data in this variable. I have 8 channels for conversion, and each conversion is stored in the last memory address + 16 bits. All sizes of all arrays used are 16 bits. The ADC has 12 bit resolution so this should be no problem for variable types/sizes.
Both arrays are uint16 arrays.

Jim, that is a great point. I assumed conversions would stop during a transmission complete, but when looking into it that is not true! I will do some testing tomorrow to see if that fixes the problem.

Thanks for the tips you two!

I couldn't wait, I went and tested it and Jim you were right. I will be using this forum more often. Thanks again for the help.

Nice one Jim -- I hadn't thought of that. I thought the M3 was like other ARMs in that the interrupts would be disabled on an interrupt unless you re enabled them. But after a quick Google I found that this is not the case - learn something new every day. Glad you found the problem!