Forum: Mikrocontroller und Digitale Elektronik LPC1768, Probleme mit RAM AHB32, LPCexpresso


von Daniel (Gast)


Lesenswert?

Moin Forum,

ich beschäftige mit gerade mit einem LPC1768 und habe ein paar Probleme 
mit dem RamAHB32. Dieses SRAM besteht aus zwei 16k-Blöcken.
Mittels #include <cr_section_macros.h> und __SECTION(bss,RamAHB32) char 
cDEBUGBuffer[1024]; kann ich ein Array in diesem Speicher erstellen. 
Laut Map und Adresse, wird dieses Array auch dort angelegt.
Ich kann in das Array Werte schreiben und diese auch im Debugger 
verifizieren. Nur leider behält das SRAM seine Werte nicht. Nach kurzer 
Zeit ist das kommplette Array '0'. Auch das lässt sich im Debugger 
sehen.
Ich habe keine Hardware, welche per DMA diesen Speicher nutzt. Wie kann 
das sein? Muss ich das SRAM noch irgendwie initialisieren, oder schreibt 
da per Default eine Peripherie rein?
Hat jemand das Verhalten schonmal beobachtet undn nen Tipp für mich?

Danke & Gruß

Daniel

von Jim M. (turboj)


Lesenswert?

> Ich habe keine Hardware, welche per DMA diesen Speicher nutzt.

Du nutzt also werder Ethernet noch USB noch den GPDMA? Diese Blöcke 
können  selbst Speicher überschreiben.

Bei meinem LPC1768 kann ich dieses Verhalten jedenfalls nicht 
beobachten.

von Grundschüler (Gast)


Lesenswert?

#define DMA_SRC      0x2007C000//AHB SRAM - bank 0   16kb
#define DMA_DST      0x20080000//AHB SRAM - bank 1  32kb
#define DMA_SIZE    0x1000 //40096/4 =1024

#define AHB_BANK0    0x2007C000
#define AHB_BANK1    0x20080000
#include <cr_section_macros.h>
__SECTION(data,RAM1) uint8_t buffer[25600];


Es sind 16+32kb SRAM. Zum testen komplett vollschreiben und dann prüfen, 
ob wirklich der gesamte Bereich auf '0' gesetzt wird. Dann ist es wohl 
ein unerwünschter Reset.

Bei meinem LPC1768 - aktuelle CMSIS - funktioniert das einwandfrei.

von Daniel (Gast)


Lesenswert?

Grundschüler schrieb:
> #define DMA_SRC      0x2007C000//AHB SRAM - bank 0   16kb
> #define DMA_DST      0x20080000//AHB SRAM - bank 1  32kb
> #define DMA_SIZE    0x1000 //40096/4 =1024
>
> #define AHB_BANK0    0x2007C000
> #define AHB_BANK1    0x20080000
> #include <cr_section_macros.h>
> __SECTION(data,RAM1) uint8_t buffer[25600];
>
> Es sind 16+32kb SRAM.

Es sind 16+16kb=32kb im AHB SRAM. Insgesamt hat der 1768er 64kb.

0x2007 C000 - 0x2007 FFFF AHB SRAM - bank 0 (16 kB),
0x2008 0000 - 0x2008 3FFF AHB SRAM - bank 1 (16 kB),

Problem ist gelöst... Irgendeine Routine in den tiefen des IP-Stacks hat 
sich mal die komplette 16k-Bank als Cache für Pakete reserviert. Kein 
DMA. Weil das direkt über einen Zeiger lief, bekam der Linker davon 
nichts mit und hat genau in diesem Bereich mein Array plaziert was 
überschrieben wurden.
Habe ein paar Änderungen durchgeführt und jetzt bleibt der SRAM auch 
unangetastet bzw. wird nicht mit o überschrieben.

Danke

von Jim M. (turboj)


Lesenswert?

Genau für solche Probleme hat der Cortex M3 eigentlich 
Hardware-Watchpoints. Der kann bei Modifikationen im RAM durch die CPU 
triggern, und Dir so verraten wer da Speicher überschreibt.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.