• State Resolved
  • Replies 29 replies
  • Subscribers 33 subscribers
  • Views 541 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

AM2634: Please let me know the reason why 0x700FFE8 ~ 0x700FFFF address shown ??

YoonJin Kim
Prodigy 110 points
Part Number: AM2634
Other Parts Discussed in Thread: SYSCONFIG

Tool/software:

Hi,

There is some strange situation at my side.

From 0x700FFE8 to 0x700FFFF memory address, you can see my capture(#1) ?? mark in Trace 32.

?? means that Trace 32 couldn't access.

This area is located in ROM Memory map. We are input the text and const value in ROM. 

RAM : origin=0x70000000 length=0x40000
ROM  : origin=0x70040000 length=0xB0000
I captured situation as below.
#1 case : I, D-Cache Enabled, Region 4 type :no Shareable, Outer and Inner write-back/write-allocate -> We can't access 0x700FFE8 to 0x700FFFF memory address
#2 case : I-Cache Enabled, D-Cache Disabled, Region 4 type :no Shareable, Outer and Inner write-back/write-allocate -> We can see the value in 0x700FFE8 to 0x700FFFF memory address.
 
In #2 case, Eventhough we could see the value in 0x7007FFE8--0x7007FFFF, Memory Protection is occurred after running D-Cache Disabled also.
I don't understand that why specific area 0x700FFE8 to 0x700FFFF memory address can't access only. As you can see the capture, other memory address accessing is allowed and we can see the Value.
And, from 0x70000000~070010000 (1MB) is same Region type. Excepting 0x700FFE8 to 0x700FFFF memory address, I can access.
In case of #1, if we are trying to access 0x700FFE8 to 0x700FFFF area, memory protection violation is occurred.
Please let me know the reason why We can't access in case of #1 case.
We must enable I, D-Cache for perfromance.
  • 0
    TI__Guru*** 131920 points

    Hello YoonJin,

    It sounds to me like you might have some wrong memory map definitions?

    From our technical reference manual for AM2634 Table 2-1. AM263x Memory Map (continued) on Page 36:

    Region Start Address End Address Size
    L2OCRAM  0x7000 0000 0x701F FFFF 2 MB

    That doesn't align with the memory map defines you provided above.

    Where did you get these details from:

    YoonJin Kim said:
    RAM : origin=0x70000000 length=0x40000
    ROM  : origin=0x70040000 length=0xB0000

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 110 points

    Hi,

    Yes. memory map for L2OCRAM 2MB is correct. we just seperate L2OCRAM 2MB to allocate .data .rodata .text and .bss.

    This is just our memory mapping to indicatie and know region internally. I know there is no ROM in AM2634.

    Please let me know why  0x700FFE8 to 0x700FFFF memory address is has problem which I asked you above.

  • 0 in reply to YoonJin Kim
    TI__Guru*** 131920 points

    Hello YoonJin,

    I spent some time today looking into this further but need to pull in other experts to review this issue.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 110 points

    Hi,

    Thanks. Please let me know as soon as possible

    I am trying to find the root cause. But I couldn't find it too at the moment

  • 0 in reply to Ralph Jacobi
    Prodigy 110 points

    Please see the my capture.

    After MCR p15, 0, r1, c1, c0, 0 // enabled cache RAMs, 0x7007FFE0--0x7007FFFF are is changed to ????????.

  • 0 in reply to YoonJin Kim
    TI__Guru*** 131920 points

    Hello YoonJin,

    Either need to get more clarity on the exact address or we figured out the root problem here but...

    YoonJin Kim said:
    0x700FFE8 to 0x700FFFF

    These are not complete 32-bit addresses. You'd be trying to access space in the Core-specific Internal Memory Map which are not part of expected device memory map.

    YoonJin Kim said:

    After MCR p15, 0, r1, c1, c0, 0 // enabled cache RAMs, 0x7007FFE0--0x7007FFFF are is changed to ????????.

    While I don't know exactly what is occurring here, it doesn't seem related to the core issue. Is there any specific key data stored there? Also what happens on subsequent steps?

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 110 points

    Hi,

    No, from 0x70040000 to 0x700F0000 area, there is text and const is located. There is no specific key data.

    I don't have an idea what kind of information should be shared with you at the moment.

    Code is in 0x7007FFE0 ~ 0x7007FFFF and if application try to access this code, then MPU violation is occurred and it goes to protection hook.

    Try to testing, I used previous our application.

    As you can see the below, I try to step by step to this phenomenon occurring.

    When I enabled MPU(M bit) and MPU region 1, this phenomenon occurred.

    At the moment, I suspect that this is not related to D-Cache enable.. 

  • +1
    TI__Prodigy 220 points

    Hi YoonJin,

    Its strange that you are seeing this issue.

    1. Just to confirm, have you tried to access this memory region in CCS?   

    2. I hope disabling D-Cache is not the solution that you are going to use because it is not recommended to disable D-Cache and also I-Cache. 

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    Hi,

    We are using AUTOSAR stack. We don't use CCS.

  • +1 in reply to YoonJin Kim
    TI__Prodigy 220 points

    In that case, can you please share the R5F MPU register values for all the regions that are programmed? Also, please make sure to read them at the point where that memory region is not being read.

    Thanks

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    Hi, 

    Do you want me to share below?

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    Related to

    - Also, please make sure to read them at the point where that memory region is not being read.

      -> I don't understand what you mean. 0x7007FFE0--0x7007FFFF is always show question mark in case of after enable MPU.

      -> And not only question mark is problem, as I mentioned case #2, #2 also problem.

  • 0 in reply to YoonJin Kim
    TI__Prodigy 220 points
    YoonJin Kim said:
    I don't understand what you mean.

    Actually, you shared with I wanted. I wanted to see MPU settings. Thanks for the above image.

    Can you try to access the same location using C/C++ pointers. Idea is to check if the C/C++ code is able to access that location.

    - If it is not able to access that location, then that program will go into hardware prefect/data abort exception.

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    Hi,

    Please see the below. Try to acess 0x7007FFE8 memory address and then after that MPU is occurred.

  • 0 in reply to YoonJin Kim
    TI__Prodigy 220 points

    was C code able to access that memory location? 

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    No, MPU Protection is occurred

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    Hi.

    is there any feedback?

  • 0 in reply to YoonJin Kim
    TI__Prodigy 220 points

    Hi YoonJin

    I have attached a very simple R5F program which configures MPU in same manner in which the above MPU are programmed in your case. Please run this program at your end and let me know if you see the above issue.

    Pause this program at starting of main and then check the MPU registers and intended memory range.

    4331.empty_am263x-cc_r5fss0-0_nortos_ti-arm-clang.zip

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    Hi,

    There is no issue in your project.

    Could you build again with accessing 0x7007FFE8 using C pointers?

    As I said before, in case of #2, I can see the value of the 0x7007FFE8, nevertheless it occur MPU violation if I try to access there.

  • 0 in reply to YoonJin Kim
    Prodigy 110 points

    Hi,

    At my side, not only 0x7007FFE8-0x7007FFFF, but 0x700FFFE8-0x700FFFF has also issue.

    I try to search issue from 0x70000000 to 0x701FFFF, there is 2 memory area has same issue.

    That's so strange. I don't understand the reason.

  • 0 in reply to YoonJin Kim
    TI__Prodigy 220 points

    Hi

    I was OOO last week. But this seems not a straightforward issue to debug.

    Just to summaries:

    1. TI tried to replicate the issue on a very minimal application with the information that is provided. TI was not able to do that based on the information that is provided.
    2. Neither the C code nor the JTAG is able to access the memory range 0x7007FFE8-0x7007FFFF and 0x700FFFE8-0x700FFFF

    Can you please answer some more question:

    1. Are you using bootloader provided by TI or some other 3rd party?
    2. Can you break just after configuration of MPU and see if you are able to access the memory?

    The way I think to debug this issue is to try to replicate the issue at my end. Can you maybe try to recreate the above issue in a very minimal application which can be shared to us? 

  • 0 in reply to Sanmveg Saini
    Prodigy 110 points

    Hi,

    1. Are you using bootloader provided by TI or some other 3rd party?
      1. 3rd party bootloader.
    2. Can you break just after configuration of MPU and see if you are able to access the memory?
      1. After just enable MPU, Can't access the memory.

    Please see the below link. I think current issue is same with below issue. This issue is not the our project specific.

    https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1303980/am2634-after-the-mpu-is-configured-the-memory-cannot-be-accessed/4982219?tisearch=e2e-sitesearch&keymatch=%25252520user%2525253A589992#4982219

    This is the reason of current issue.

    But still I don't understand why we can't access specific memory address which are 0x7007FFE8-0x7007FFF and 0x700FFFE8-0x700FFFF.

    From the above link, I have question.

    Q1. Above link commented that "last 32Bytes of an MPU region". But actually "??" is shown only 24 bytes. I don't understand why 32 bytes.

    Q2. And we are using SRAM from 0x70000000 to 0x70200000. Which memory area should I consider as "the last 32 bytes of an MPU region"?

    Please let me know your feedback..

  • 0 in reply to YoonJin Kim
    Prodigy 110 points

    Hi,

    Is there any update?

  • 0 in reply to YoonJin Kim
    Prodigy 110 points

    Hi, ,

    Is there any problem? There is no any update during 10days.

    Please let me know the feedback on my question.

  • 0 in reply to YoonJin Kim
    TI__Guru*** 131920 points

    Hi YoonJin,

    Without being to replicate the issue on our end the root cause is difficult to help answer.

    YoonJin Kim said:
    Q2. And we are using SRAM from 0x70000000 to 0x70200000. Which memory area should I consider as "the last 32 bytes of an MPU region"?

    It would depend on your configured MPU region that's why the post is left not-specific. You determine the range based on MPU configuration.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    TI__Guru*** 131920 points

    Hello YoonJin,

    I got the following feedback:

    Please refer to the note at the top of Page 65 of the device Technical Reference Manual: https://www.ti.com/lit/ug/spruj17f/spruj17f.pdf#page=65

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 110 points

    Hi,

    Sorry for late reply due to our long holidays.

    It would depend on your configured MPU region that's why the post is left not-specific. You determine the range based on MPU configuration.

    -> I don't understand how to figure out it from the my MPU region configuration.

    You can see the below capture which is configuration of MPU region, and I can't get any hint from the capture. So that reason I asked you related to Q1 and Q2 question.

    Can you figure it? If you can please let me know Q1 and Q2.

    - Why 24 bytes is accessing fails differ from the note at the top of Page 65 of the device Technical Reference Manual. Technical Reference Manual noted 32bytes.

    - Why we can't access 0x7007FFE8-0x7007FFFF and 0x700FFFE8-0x700FFFF range. I can't infer from the below MPU configuration.

  • 0 in reply to YoonJin Kim
    TI__Guru*** 131920 points

    Hello,

    YoonJin Kim said:
    -> I don't understand how to figure out it from the my MPU region configuration.

    You need to look at your MPU configuration in SysConfig and then determine your start / end addresses accordingly. That will help you identify the location of the final 32 bytes of the MPU region.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 110 points

    Hi,

    We are not using SysConfig.

    But I can see the MPU region configuration from the register value and above capture is my MPU configuration.

    Below is translate the MPU configuration.

    From the MPU configuration, there is no any suspicious things related to this issue.

    I couldn't find any correlation related 24 byte and 32 byte and also 0x7007FFE8-0x7007FFFF and 0x700FFFE8-0x700FFFF range.

    Could you let me know where I can identify final 32 bytes from the my configuration please?

           - As I mentioned above, issue is occurred at 0x7007FFE8-0x7007FFFF and 0x700FFFE8-0x700FFFF with 24byte size

    Region Start Address End Address Size XN S AP Type
    0 0x0 0x80000000 2GB - Yes Full Strongly-ordered
    1 0x70000000 Disabled
    2 0x70000000 Disabled
    3 0x0 0x8000 32KB No Full Outer and Inner write-back/write-allocate
    4 0x70000000 0x70100000 1MB No Full Outer and Inner write-back/write-allocate
    5 0x701FB400 0x701FB600 512B NoExec No Full Outer and Inner write-back/write-allocate
    6 0x7018FFE0 0x70190000 32B NoExec No Full Outer and Inner Non-cacheable
    7 0x50D00000 0x50D04000 16KB NoExec Yes Privileged Outer and Inner Non-cacheable
    8 0x700E0000 0x70100000 128KB NoExec No Full Outer and Inner Non-cacheable
    9 0x0 Disabled
    10 0x0 Disabled
    11 0x70190000 Disabled
    12 0x70190000 Disabled
    13 0x70190000 0x70198000 32KB No Full Outer and Inner Non-cacheable
    14 0x70120000 0x70130000 64KB NoExec No Full Outer and Inner write-back/write-allocate
    15 0x70100000 0x70110000 64KB NoExec No Full Outer and Inner write-back/write-allocate