CODEWITHSUNDEEP
carmembedded
Kodiak
Kodiak

Reputation: 87

memcpy() overflow? Every eighth byte has its same bit pulled down when reading from FLASH

The problem

When executing a memcpy() to copy 8kb from a FLASH memory region (aligned on sector boundary) to a buffer allocated on the heap, a seemingly un-related printf() statement is mangled.

I have tried to copy fewer bytes, doing it parts, using a buffer allocated on the stack instead of on the heap, etc. However, in all these cases, the mangling is still happening, so it seems that purely the execution of the memcpy() itself is already causing this problem.

The code Unfortunately, the code is aimed at an embedded platform, so reproducing the problem is likely troublesome. Nevertheless, this is where the corruption happens (at the memcpy()):

uint8_t *pInitReadBuffer = malloc(nvsRegionAttrs.regionSize);
if (!pInitReadBuffer)
{
  printf("Could not allocate memory (%s:%d)\n", __FILE__, __LINE__);

  return;
}

// TODO Fix this
memcpy((void *) pInitReadBuffer, nvsRegionAttrs.regionBase, nvsRegionAttrs.regionSize);

The disassembly

84         memcpy((void *) pInitReadBuffer, nvsRegionAttrs.regionBase, nvsRegionAttrs.regionSize);
            $C$L3:
0000a51c:   4920                ldr        r1, [pc, #0x80]
0000a51e:   4A21                ldr        r2, [pc, #0x84]
0000a520:   9800                ldr        r0, [sp]
0000a522:   6809                ldr        r1, [r1]
0000a524:   6812                ldr        r2, [r2]
0000a526:   F001FEDB            bl         #0xc2e0
101         free(pInitReadBuffer);

The data

Original string: [GPRS]: Waiting for GPRS UART task to start up
Mangled string: KGPRS]: Gaiting for GPRS UART tack to start up

What does this show us? That every eighth character (byte) is being mangled. In fact, the mangled characters show us that even their same bit is being pulled down. The ASCII value of K (75) is 16 less than that of [ (91). The same goes for the W that became a G, and the s that became a c.

Extra information based on the comments of Jonathan Leffler, Chris Stratton, and D Krueger

Unfortunately, I do not understand what is causing this weird behavior, and how to solve it, even with all this information.

I would very much appreciate some insight!

Upvotes: 1

Views: 315

Answers (1)

D Krueger
D Krueger

Reputation: 2476

The issue has nothing to do with the function shown, but with code called previously. Somewhere the FLASH array was placed in command mode and never returned to read mode. The "corrupted" bits seen are actually set to zero by the device to communicate the FLASH command status.

Two likely causes of this behavior:

  • A FLASH command is executed but the command to return to read mode isn't.
  • The read-mode command is issued, but without waiting for completion of the prior FLASH command.

Upvotes: 4

Related Questions