This is pretty frustrating. I am working with a modified copy of the usb_mass_storage app which includes the most recent changes to adi_usb_msd_scsi (fixes for Windows 7 etc)
In general this is being tested on an BF526 EZBRD but also on custom BF524 hardware with an otherwise identical memory map etc. So this means both test beds have 64MB of SDRAM.
My question is this:
How do I ensure the application has a sufficiently large heap (10MB) to allocate space for the RAM disk without running into
'External memory is disabled for this region of memory' warnings and subsequent crashes.
I have 2 scenarios, both of which fail in different ways. What I'd love to get is a solution that works repeatably and consistently. Sometime there is far too much voodoo involved with the processor and toolchain ...
The pattern is simple:
A. Call adi_ssl_init() to set up hardware.
B. Set up USB controller, USB driver
C. Enter loop waiting for connect/disconnect events.
1. Failure to allocate 8MB RAM disk
1.1 Project has no LDF file.
1.2 Project is set to use external 64MB SDRAM
1.3 malloc fails for any request larger than around 8KBytes
2. EXCAUSE 21 errors
2.1 Project has an LDF file
2.2 Project is set to use external 64MB SDRAM
2.3 System heap set to minimum size of 10MB in L3 external SDRAM
2.4 Cache and memory protection is disabled.
2.5 'External memory is disabled for this region of memory' warnings when loading target via JTAG
2.6 malloc works on entry to main()
2.7 Project crashes with EXCAUSE 21 and HWERRCAUSE 03 in adi_ssl_init()
2.8 Resetting the target has no effect on the 'disabled memory' warnings.
The project complete with LDF (VDSP5.0 Update 10 Windows 7 x64) is attached.
For anyone else treading the same path, here are some tips:
1. Application was (apparently) running out of stack in adi_ssl_init.c.
2. There is a good chance the code has grown beyond internal memory space but there is no warning from the linker about this.