This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

p2p example failing with "Trouble Reading Memory Block at 0x20030004"

Other Parts Discussed in Thread: UNIFLASH, CC3200

As per subject, I'm building the p2p project along with driverlib and simplelink. There don't appear to be any link errors.

I'm getting an error on the console: "Cortex_M4_0: Trouble Reading Memory Block at 0x20030004 on Page 0 of Length 0x4: Debug Port error occurred". Given that 0x20000000 appears mapped onto the SRAM this is problem. It actually stops at the first line of main.c. Any ideas?

Thanks,
Dave

  • Do you try to format the flash and try again?

  • Umm, no. How do I do that? (somewhat new at embedded).

    -Dave

  • format  the flash with Uniflash application

  • Everything might actually be okay.   I think error is just a warning message because it is trying to read a location that hasn't been initialized (?). At least, I've been seeing that warning and ignoring it...

     When starting up, the debugger always stops at the beginning of main.  Just hit the continue/play button and see if it works.

  • Mark, that is exactly what I have been doing when running the examples.  I think it is probably because the demo code is still in RAM and that area is protected somehow.  I haven't looked to closely at the memory .map or list file to see what is put where yet, but eventually we need to know the reason.

    Thanks,

  • Well *that's* embarrassing, I can't get uniflash to work, either. I've set the com port number correctly and can connect a different terminal and get numbers back so that's good. It's set to 115200 in the driver's property screen but is otherwise stock.

    I press reset when I'm told.

    Any ideas?

  • Dear David,

    This reply is to your initial post.

    "Trouble Reading Memory Block at 0x20030004".

    Currently in CC3200, RAM is limited to 176KB so the the memory access while loading the program should be a RAM Address between (0x20004000 to 0x20030000)

    So I guess the issue is related to the linker command file(.icf in IAR, .cmd in CCS).

     I understand you are using CCS. Please refer to the cc3200v1p32.cmd file in cc3200-sdk\example\p2p\ccs. You can refer to other example folder as well.

    Please let us know if this helps

    Regards,

    Kaushal

  • Hello Kaushai,

    Are you saying that the RAM isn't the 256KB as outlined in the documentation or was the 176KB a typo?

    Thanks,

  • Greenja,

    RAM is indeed 256KB, but currently only 176KB is available to MCU in CC3200Z devices.

    Part of the RAM is reserved. Please refer cc3200-sdk\docs\CC3200-Programmers_Guide.pdf for more information about the RAM and MCU peripherals.

    Kaushal

  • Hello Kaushal,

    The Programmer's guide states that the available RAM is 240KB, only 16 KB are reserved.

    6.1.2 BootLoader User Application – Sharing MCU RAM

    In the DOWNLOAD mode, bootloader requires memory resources.These are acquired from the MCU RAM.  The amount of RAM used by bootloader is 16KB.This implies that for the production CC3200R device, user application image needs to be restricted to 240KB for the 256KB MCU RAM variant of  CC3200.

    There is no mention of CC3200Z devices.

    Thanks,

  • Hello Greenja

    Let me re-phrase the specifics

    • CC3200 Production Device would have 256KB of RAM interfaced to MCU
    • CC3200 Pre-production Device [one that you have on your Lauchpad] has 192KB of RAM interfaced to MCU (this is captured in the CC3200 SDK release notes - section#10.4)
    • Now as mentioned in the Programmer's Guide (Section 6.1.2), 16KB of RAM (lower end of the memory map) is used by CC3200 MCU bootloader - hence limiting the user application image size on the pre-production device to 176KB.
      • Please note that the above mentioned 16KB block can be used by the user application for its run time data requirement (viz. Stack, Heap etc..)

    Please do let us know if this note answers your query

    regards

    Manav

     

     

  • Hello Manav,

    The information you provided answers my question.  It also raises another one.

    I have noticed that users of early versions of LP have been told that they have to get a new board because the software/firmware doesn't support it.  Will we face the same issue with this Pre-production Device?  

    Are we going to be told that the new releases of the software/firmware are not supported on our LP and will have to get new ones?

    Thanks,

  • Greenja, no. The released Kits will be supported for considerable time. Ofcourse, as we launch updates to the base Si we will make updated kits available with the newer Si on them. However, we will continue to support the existing kits for considerable time so that your evaluation and development with the kits can be completed

    Cheers,
    Gagan

  • Hi Gagan,

    I am getting the same error message and have gone back to check the .cmd file. Everything looks fine since the:

    RAM starts at 0x20004000 ie the bottom 16Kb is excluded

    CODE is defined from 0x20004000 to 0x20016FFE (length 0x00012FFF not 0x00013000)

    1 byte is left open at 0x20013FFFF

    DATA is defined from 0x20017000 to 0x2002FFFF (length 0x00019000)

    Q: The definition indicates that no memory should be expected at 0x20030000, why is the debugger trying to read there?

    Q: Why the single byte left undefined between CODE & DATA

  • Problem has been solved, fault is in definition in the cc3200.gel file. Full details of the changes in another post, just search for cc3200.gel André
  • where can i find these cc3200.gel files?

    en how do i change them

  • Hi Sebastian,

    As per other post, can be found at https://github.com/ammaree/cc3200/blob/master/various/cc3200.gel

    andre