• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Subscribers 350 subscribers
  • Views 6777 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Arm1176 processor is getting hang, when I use Multiple register data transfer instructions, my Stack pointer is in DDR

Ratan

Tried with bare code, the DDR stack behavior is fine when we use recursive function call passing multiple arguments, but, when I use Multiple register data transfer instructions shown in below example, processor is getting hang.

Example:

stmed sp!, {r0,r1,r2,r3}

ldmed sp!, {r0,r1,r3,r4}

Also tried with reducing the DDR frequency (360MHz, 340MHZ) configuration and changing the mode registers and enabling auto refresh mode, still we don't see any difference in DDR stack pointer.

But I am able to write the pattern into my DDR device. 

 

processor : arm1176

DDR conrtoller : Denali datbhan

DDR device :  MT47H128M16RT-25E

  • 0
    The usual stack handling is with STMFD / LDMFD not STMED / LDMED. Did you mean ED? It might be causing a word to be overwritten if mixed with FD.
  • 0 in reply to daith
    In one of the function , we have the translated assembly code shown below, while exeuting the instruction, we got data abort , AEM1176 Processor got hang.

    stmia r5!, {r0, r1, r2, r3}

    Stack pointer is pointing to DDR

    Is there any parameter in DDR, de we need to consider?
  • 0 in reply to Ratan

    Just to be certain, I am assuming r5 points at a word boundary, and this is before you've set up virtual memory and caching which would be doing burst transfers anyway.

    I would have though Denali were the ones to ask if a problem in setting up the controller is suspected. In this case it would probably be something about the handling of burst transfers. However before going there what you'd really need is two programs that differ from each other in just a small area that causes the problem. This would make it easy to see that this is not due to anything else. Here one could for instance break the stmia into individual stores for instance
    str r0,[r5]
    str r1,[r5,4]
    str r2,[r5,8]
    str r3,[r5,12]
    add r5,r5,16
    and this would be the version that didn't get a data abort when it got here (though it might get one later at another stm).

  • 0 in reply to daith
    we did some couple of test on bare metal code, in that we want to read and write to DDR locations,
    Arm11 got hanged for the following instructions
    stmda, stmfa,stmed,stmib

    where, r5 is pointing to DDR location
    for ex:
    stmda r5!, {r0,r1,r2,r3}
    stmfa r5!, {r0,r1,r2,r3}
    stmed r5!, {r0,r1,r2,r3}
    stmib r5!, {r0,r1,r2,r3}
    ldmia r5!, {r0,r1,r3,r4}

    For other instruction of ldm and stm, it works fine,where r5 is pointing to DDR location

    above all the instruction are working fine, when r5 is pointing to on-chip-memory

    could you please suggests the solution, Thanks in advance
  • 0 in reply to Ratan

    Sorry I hadn't quite taken in that you really did mean hang. The difference between those STM instructions and others is that they all store at 4 or 12 behind the address rather than at 0 or 16 displacement. So that's good evidence that there is a problem with the AXI transactions. between the processor and the DRAM controller and that's what needs to be looked at. I would guess the other STMs go wrong and these work okay if you increment r5 by 4 as the processor has a 64 bit wide interface.

  • 0 in reply to daith
    can you explain this below statement in more details
    1."the difference between those STM instructions and others is that they all store at 4 or 12 behind the address rather than at 0 or 16 displacement"
    2. "evidence that there is a problem with the AXI transactions between the processor and the DRAM controller?"

    can you provide the pseudo code for below statement
    3. I would guess the other STMs go wrong and these work okay if you increment r5 by 4 as the processor has a 64 bit wide interface.

    Based on you suggestion we have modified the AXI register, AXI(0-7)_EN_SIZE_LT_WIDTH_INSTR bit field to 0xffff, the bare code was executed fine without any issue. Thanks for your inputs :)


    Can you give more information regarding AXI register, AXI(0-7)_EN_SIZE_LT_WIDTH_INSTR bit field to 0xffff
  • +1 in reply to Ratan

    About AXI, you're better asking somebody other than me. Perhaps raise another question that specifically mentions AXI in the title or/and set tags mentioning amba and axi. Or contact whatever support you have about it.

    STMED = STMDA r5!,{r0-r3} stores four words at r5-12 and r5 is set to r5-16

    STMFA = STMIB r5!,{r0-r3} stores four words at r5+4 and r5 is set to r5+16

    STMFD = STMDB r5!,{r0-r3} stores four words at r5-16 and r5 is set to r5-16

    STMEA = STMIA r5!,{r0-r3} stores four words at r5 and r5 is set to r5+16

    Halting is the sort of thing some interface protocol going wrong is liable to do with both sides waiting for the other. Plus the problem was happening with a number of transfers starting on a word but not double word boundary which didn't sound like anything at either end but something in the middle. Also there seem to be a number of questions about burst transfers on this board and alignment and the protocol isn't altogether straightforward. Getting memory transfers working fast is very important and speed is often the enemy of simplicity. So I think it is worth asking further to make sure your settings are good as you don't want to halve your memory access speed by mistake.

    I suggested the change by 4 would make one set of STM's work and the other fail as then the ones that failed would start on an 8 byte boundary and the others would not