heap memory part write protected?

Now that I try to home on what is going on here I see that sometimes even writing to allocated memory in normal code fails, although it appears no where as often.

A 'version' of the test code always fails in the same ways in the same locations, but as soon as the test code is changed the 'errors' can change in size and/or location.

Eg the current test program allocates 64kb of ram, the part that writes to the 64kb works fine, the part that reads 64kb from a file has holes 0x000-0x000F, 0xFFD0-0xFFDFF and 0xFFF8-0xFFFF

Are you sure there is really freely usable RAM available at these addresses? Looks like your'e poking around in some registers/interrupt vector tables...

I think so, the following memory dump starts at 0x800c0460, which I take to be inside the Sitari memory space

EMIF0 SDRAM 0x8000_0000 -> 0xBFFF_FFFF

A1E8A1E8 A1E8A1E8 A1E8A1E8 A1E8A1E8
A1E8A1E8 A1E8A1E8 A1E8A1E8 A1E8A1E8
00110010 00130012 00150014 00170016
00190018 001B001A 001D001C 001F001E
00210020 00230022 00250024 00270026
00290028 002B002A 002D002C 002F002E
00310030

This is what the debugger dumps after 64kb has been filled with 0xA1E8, it also verifies the memory as being correct!?

After the file is read errors are found

0x800C0460 - 0x800C047F (data not read off uSD, still contains 0xA1E8 from above)

0x800D0240 - 0x800D025F (data not read off uSD, still contains 0xA1E8 from above)

0x800D04580 - 0x800D045F (data not read off uSD, contains 0x0000, 0xA1E8)

Is there some cache that needs to be invalidated?

Mark

I checked internally, here is there response I received:

As per my understanding the customer is using the Starterware Filesystem API f_read() to read from MMC and copy to the Heap memory(allocated using memcpy).  The Data CACHE Invalidate is not required after the f_read() since it is done in the MMCSDReadCmdSend(). I am not sure whether he is properly enabling the MMU and cache. There is an example cache_mmu as part of the example on the usage of the cache invalidate/clean APIs

Hopefully this helps.

  Paul M.

Meanwhile I noticed something very similar: when reading blocks of data from SD-card, there sometimes comes a 0 in between where some other data should have been read. So for me it does not seem to be the target RAM but the read function that sometimes simply misses data.

Where I'm not sure at the moment: it possibly may be caused by compiler or its optimisations. So depending on which optimisation level I use, reading fails completely or it works with these gaps in data. And sometimes it seems to help, to just to change some other code and recompile the whole thing to move the gap to an other position in read buffer.

But for this reason I'm definitely not sure, I'm still investigating it. Only the fact some data are sometimes not read can be verified by me.

Paul,

Yes, that is indeed what the program is doing.

It uses the 'standard' MMUConfigAndEnable() routine used in many of the starterware samples. This, to me, enabled cache across the entire 512MB of DDR memory.

Of course, I have no idea if extra steps are required when using malloc, I am having great difficulty following some of the documentation.

Hans, Have you gotten any further?

Mark van der Eynden said:

Hans, Have you gotten any further?

Unfortunately not very much. It seems like there is a problem with data transfer from device, I noticed these read-drops also may happen when reading the FATFS-data structures not only when reading some data on FATFS. This results in SD card/partition not being recognised.

So I only can guess the data transfer (DMA?) is sometims not as stable as it should be.

In my tests I found that when the target of the read was statically declared it worked fine, it was only when the memory was malloc'd that there was an issue. Are you seeing it both ways?

Hm, no, I didn't noticed such a difference. Are you sure it is really the malloc-replacement and not simply because you had some other code the compiler optimised in a different way and therefore did not stumble upon this problem just accidentially?

I'm still quite green with this platform, so what you way is possible.

At one stage I was thinking change the code added or moved the issue, but since I've put the diagnostics in, it seems to be pretty 'fixed' in its behaviour.

What compiler optimizations would you suggest I try playing with?

Mark van der Eynden said:

What compiler optimizations would you suggest I try playing with?

Optimisation level (O0..O4) and speed-vs-size settings seem to make a difference. Within my project specific settings of both can make the difference between "FATFS on SD card not recognised" and "reading from SD-card seems to work fine". I can't tell you which settings are good or bad, since they seem to be application-specific.

Only thing I found: platform-lib should be compiled with absolutely no optimisations, this will make more than only file system access unusable.

Interesting changing the Optimization level and/or speed-vs-size settings changes the start address of my 64KB buffer (as you would expect), and it also changed the size of the 'chunks of errors' quite a bit.

This would, to me tend to suggest that there is indeed something rotten, that has nothing to do with my actual code.

Be nice if someone from TI could post a simple starterware app to read a block off the uSD and hence either see the problem for themselves, or else, show us where we are going so wrong.

Where does one find/alter the 'platform-lib' optimizations?

When you found out what the optimisation levels are doing (wrong) with your code exactly, this would be a question for the compiler forum, they should have a non-Starterware-specific answer to it (and support by TI is much better there).

Platform-lib is something you already should have compiled, elsewhere I don't know how you can access SD-card ;-)