Jump to content
  • 0

CMOD A7 OOB project - mem test stamps on its own codespace!?


danmcb

Question

Well, I'm using the lockdown to do some playng around with the CMOD A7 board that I bought a while back.

After some fighting with Vivado/Vitis I did manage to setup and build the OOB project. However on a terminal I noticed that the microblaze always seems to die on the memory test.

I also saw a lot of flaky behaviour of the debug/terminal connetion. I have to restart Vitis many times and so on.

Eventually I realised the issue ... the memory test seems to be stamping on ts own code area!

Here is output of the running app:

--Starting Memory Test Application--
NOTE: This application runs with D-Cache disabled.As a result, cacheline requests will not be generated
Testing memory region: Cellular Ram
    Memory Controller: emc
         Base Address: 0x60000000
                 Size: 0x0007ffff bytes

but here is the output of the downloader:

Downloading Program -- /home/daniel/work/vivado/Cmod_OOB/vitis/Debug/CMOD_OOB.elf
    section, .vectors.reset: 0x00000000 - 0x00000007
    section, .vectors.sw_exception: 0x00000008 - 0x0000000f
    section, .vectors.interrupt: 0x00000010 - 0x00000017
    section, .vectors.hw_exception: 0x00000020 - 0x00000027
    section, .text: 0x60000000 - 0x600032ff
    section, .init: 0x60003300 - 0x6000333b
    section, .fini: 0x6000333c - 0x6000335b
    section, .ctors: 0x6000335c - 0x60003363
    section, .dtors: 0x60003364 - 0x6000336b
    section, .rodata: 0x6000336c - 0x60003a0b
    section, .sdata2: 0x60003a0c - 0x60003a0f
    section, .data: 0x60003a10 - 0x60003d33
    section, .sdata: 0x60003d34 - 0x60003d37
    section, .sbss: 0x60003d38 - 0x60003d37
    section, .bss: 0x60003d38 - 0x60003e47
    section, .heap: 0x60003e48 - 0x60004647
    section, .stack: 0x60004648 - 0x60004a47

How is this supposed to work? is there something strange with my project? perhaps the microblaze is meant to be running out of some other RAM block? is there some liner config in Vitis that I missed?

(EDIT :

after some more prodding about, I found that indeed I seem to have the wrong linker script lscript.ld - there was another one which uses local memory instead of the external RAM.

but when I replace it, Vitis complains that the hardware info eported by Vivado is not valid. So I guess this was somehow generated by Vivado -but where?)

thanks!

 

Daniel

 

 

 

 

Link to comment
Share on other sites

1 answer to this question

Recommended Posts

well, I'll answer my own question.

Basically, just changing to the correct ldscript.ld file fixed things. Initially Vitis complained about the board config, but I ignored it, rebuilt everything and now the build works fine. The working memory is internal to the FPGA, and the external SRAM can be tested fine with the demo code.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...