Here:

s2      strobe_s *          0x800a497 <_fflush_r+66>   

s2is a flash (read-only) address. Copying to read-only memory is both semantically erroneous and may trigger an MPU fault if the region were set to read-only.

It is not clear to me how the original code worked or indeed how:

 *s1 = ss->strobe;

is not causing a problem too however. Certainly it won't work as intended even if there were no exception.

Several problems:

• DMA buffers need to be volatile qualified or otherwise the compiler might go bananas when generating the code accessing them.

• You use memcpy incorrectly, should have been memcpy(Wave_Active , Wave_High, sizeof Wave_Active);

• The use of memcpy to begin with is often incorrect when it comes to hardware-related programming. Copying 256 bytes takes a lot of time. Worst case, your DAC might even request new data before you are done copying.

  The correct way to write such code would be to have several allocated buffers, then swap an "active" pointer to point at the one used. With the disclaimer that I don't understand the purpose of these arrays, something like this would be an immense speed optimization:

    volatile uint32_t Wave_Low[NS] = {2048,[...],2047};  # lookup table 1
    volatile uint32_t Wave_High[NS] = {4096,[...],4067}; # lookup table 2
    volatile uint32_t* Wave_Active = Wave_High;
  
    ...
    if(DMA_flag)
    {
      Wave_Active = (Wave_Active==Wave_Low) ? Wave_High : Wave_Low;
  
      /* you might have to tell the DMA which array to use next time here */
    }
  

Posted on October 11, 2013 at 01:25 · I had a related problem which I'll share as you may be experiencing the same. · I use the GCC compiler which I use to compile both C and C++ applications for STM32. When using memcpy() the compiler includes optimisations to use the stmdb and ldmia instruction to copy multiple items at a time. While the normal ldr and str instructions are able to work just fine with non-aligned memory pointers, the ldmia and stmdb instructions resulted in hard faults (although maybe memory faults). · If you use Google you can find other references to this issue, and also how to specify the variables to stop this optimisation from happening - or at least only be applied when the memory being copied is correctly aligned. I can't remember the exact details though, as I wrote my own memcpy replacement instead.

Try to check if your device has a DMA peripheral with RAM to RAM capabilities. Then just program one channel to make these kind of transactions and call it when you need to copy chunks of memory. Generally, STM32 and most other Cortex M devices have DMA. As a plus, if you need padding, some DMA peripherals allow for padding. You can also use them to zero out regions of memory by setting the byte, half or word it is reading as 0 and locking the read address.