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

I cannot write the sp register in the monitor mode

I use a Cortex-A7 board and write start up code.

I try to use Security Extension.

I use `smc` instruction and make cpu mode monitor mode.

In the monitor handler, I tried to changed stack pointer value for calling other functions.

But after execute `ldr sp, =_stack_start`, sp value is 0x0 (Of course, _stack_start is not 0x0 and I check it in the assembler code).

Therefore, after `push` some registers and `pop` those registers, the data abort excetpions occurred!

How can I change the sp value?

  • It sounds like you're using a board without an operating system, is this correct ?

    If it's a CubieBoard2, then I may be able to do some tests (I'm running Cubian on mine)

    I do not know why this is happening (it does not sound logical that this should happen at all, but there must be a reason somewhere).

    Try doing a few tests...

      ldr r0,=_stack_start

      mov sp,r0

      mov r0,0x01000000

      mov sp,r0

      ldr r0,new_stack

    mov sp,r0

      (other code here)

      b main

    newstack:

    .word 0x02000000

    ...etc.

    The first snippet I mentioned may give you exactly the same result as you had before, but at least you can see the value of r0 first.

  • It sounds like you're using a board without an operating system, is this correct ?

    Yes, I'm using a board without an OS.

    I use TWR-LS1021A board.

    I tried to load the value to r0 at first and then move sp like this:

         ldr r0, =_stack_start

         mov sp, r0

         mov r0, #0x1000

         mov sp, r0

    These code cannot change the sp value though the r0 value is not 0x0.

    I checked the manual of ARMv7-A, but I cannot find such a description that we cannot change the sp value in the monitor mode.

  • I try to do another test:

         ldr r0, =_stack_start

         mov sp, r0

         mov r1, sp

    I checked the value with J-Link debugger, and r0 is _stack_start value and sp is 0x0.

    But r1 is _stack_start value correctly.

    Therefore, it seems to the J-Link problem.

  • I think that means sp actually has the right value and it's the debugger that does not know how to read the registers properly.

    Have you tried using OpenOCD ?

  • I think that means sp actually has the right value and it's the debugger that does not know how to read the registers properly.

    I think so too, because following push and pop instructions correctly worked.

    But I don't know how to configure OpenOCD for my board.

    Could you show me your configuration file for CubieBoard2?

  • I do not use OpenOCD with my CubieBoard2, as I'm just running Linux from a SD card on this one.

    Looking further into this, I'm not sure the LS1021A is supported in OpenOCD yet (eg. I do not think there's a driver for it).

    To see the currently supported boards, list the contents of /usr/local/share/openocd/scripts/board/

    To see the possible targets, list the contents of /usr/local/share/openocd/scripts/target/

    If you feel like writing a driver for it, let me know, and I'll point you in the right direction - but it may be something that requires a fair amount of work.

    Another way might be to try a differnt IDE. Which one are you using right now ?

  • I currentry use JLinkGDBServer and J-Link edu.

    SEGGER - The Embedded Experts - Download

    This supports Cortex-A7.

    I checked /scripts/board directory but there are no LS1021A configure file.

    I also checked other directories but there are no files for Cortex-A series.

    I' m afraid that OpenOCD doesn't support this cpu.

  • I can't be sure, but I think Freescale's CodeWarrior might be able to debug the target.

    You may want to try out the KEIL tools too.

  • I thought so...

    From Public Git Hosting - openocd.git/tree - src/target/

    -rw-r--r--25367armv7a.cblob | blame | history | raw
    -rw-r--r--5442armv7a.hblob | blame | history | raw

    History says it's been there since 2009.

    Oh, and also:

    -rw-r--r--101773cortex_a.cblob | blame | history | raw
    -rw-r--r--3740cortex_a.hblob | blame | history | raw

    from history:

    2015-01-10Alexander Steincortex_a: Add support for A7 MPCore
  • For Cortex-M, a driver is needed, maybe this is not the case for Cortex-A ?

  • Driver? Which driver are you talking about?

    Connection driver (jtag, st-link, j-link, ...)?

    [EDIT]

    You mean 'board driver'?

    I think it's not necessary for simple debugging - when you don't need to know about things outside the processor itself

    (as opposed to board, SoC or core-integrated stuff, like caches) not to mention multicore debugging.

    And even then you can do that configuration if you know your system well enough.

    I'm not sure, but I'd guess the above mentioned files probably have the stuff for jtag word length, commands and other

    jtag configuration info.

    [/EDIT]

  • By driver, I actually mean a chip specific driver inside OpenOCD.

    For instance, OpenOCD cannot flash-program Kinetis KE devices, because a driver was not written in C for it.

    Thus the Kinetis KE cannot be flash-programmed, because OpenOCD does not know how to handle or recognize it.

    One cannot just use the KL driver for KE targets, because it might damage the chip if not setting the clock configuration correctly for flash-programming.

    I'm not sure whether or not it can be debugged; maybe OpenOCD would actually allow debugging without knowing which device we're speaking about.

    After all, it's a SWD protocol and OpenOCD knows the Cortex-A7 core. Thus a configuration file might be able to enable debugging.

  • Thank you for providing information.

    I installed OpenOCD from the package manager, but it is the old version.

    Threfore, I installed the 0.9.0-rc1 from the git repository.

    I find the configuration file for Raspberry Pi 2, which has four Cortex-A7 cores.

    https://gist.githubusercontent.com/jitomesky/4b564b33ef774d359d9d/raw/rpi2.cfg

    I tried to connect to the board with SEGGER J-Link with this configuration file.

    https://gist.github.com/garasubo/d3ff25e6617411412450

    But after connecting gdb, it fails as follow:

    $ sudo openocd  -f ocd.cfg

    Open On-Chip Debugger 0.9.0-rc1 (2015-04-27-13:13)

    Licensed under GNU GPL v2

    For bug reports, read

        http://openocd.org/doc/doxygen/bugs.html

    adapter speed: 1000 kHz

    adapter_nsrst_delay: 400

    Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.

    Info : J-Link V9 compiled Apr 21 2015 18:10:40

    Info : J-Link caps 0xb9ff7bbf

    Info : J-Link hw version 93000

    Info : J-Link hw type J-Link

    Info : J-Link max mem block 70896

    Info : J-Link configuration

    Info : USB-Address: 0x0

    Info : Kickstart power on JTAG-pin 19: 0x0

    Info : Vref = 1.788 TCK = 1 TDI = 0 TDO = 0 TMS = 0 SRST = 1 TRST = 1

    Info : J-Link JTAG Interface ready

    Info : clock speed 1000 kHz

    Info : JTAG tap: ls1021a.tap tap/device found: 0xa21c64cd (mfg: 0x266, part: 0x21c6, ver: 0xa)

    Warn : JTAG tap: ls1021a.tap       UNEXPECTED: 0xa21c64cd (mfg: 0x266, part: 0x21c6, ver: 0xa)

    Error: JTAG tap: ls1021a.tap  expected 1 of 1: 0x5ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x5)

    Info : JTAG tap: auto0.tap tap/device found: 0x5ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x5)

    Info : JTAG tap: auto1.tap tap/device found: 0x06b0001d (mfg: 0x00e, part: 0x6b00, ver: 0x0)

    Error: Trying to use configured scan chain anyway...

    Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x5ba00477"

    Error: auto0.tap: IR capture error; saw 0x0000 not 0x0001

    Warn : Bypassing JTAG setup events due to errors

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Warn : Invalid ACK 0 in JTAG-DP transaction

    Info : accepting 'gdb' connection on tcp/3333

    Error: Register map is not available yet, the target is not fully initialised

    Could you tell me how to configure for this board?

  • In order to dump the registers the CPU must be halted first.

    Try the 'halt' command or 'reset halt', then 'reg' should work.

    You should also be able to use the 'step' command after the CPU is halted.

    mdw shows a 32-bit word from memory, mdh shows a 16-bit word and mdb shows an 8-bit word (byte).

    mww writes a 32-bit word, mwh writes a 16-bit word and mwb writes an 8-bit word.

    arm disassemble <address> <length>

    should show you the disassembly.

  • You are not debugging on RPi2 by any chance?

    In that case you need to use the GPIO pins + a boot program to switch the

    multiplexed GPIO pins for that use. The two jtag-connectors are for LAN-chip and for GPU.

    Even if the cores are on the same chip as the GPU, (I'm told) the cores are not in the same

    scan chain with the GPU.