J-Link, GDB and STR912

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Hi marocprof and soundso,

    First of all, thank you both for sharing your str9 projects in here. I finally got my STR9 dongle working using the Yagarto/GNU/J-Link combo.

    So I moved on and tried to port the ST library (downloaded from the link below) into my Eclipse project.

    However, I got a whole series of errors during compilation. When I imported the 91x_scu.c file specifically, I got the following error when I built:

    Source Code

    1. make all
    2. arm-elf-gcc -mcpu=arm966e-s -c -g -gdwarf-2 91x_scu.c -o 91x_scu.o -I. -Ilibrary/inc
    3. arm-elf-gcc -mcpu=arm966e-s -S 91x_scu.c -I. -Ilibrary/inc
    4. arm-elf-gcc -mcpu=arm966e-s -nostartfiles -o skeleton_RAM.elf -T STR91xx44_RAM.ld startup_STR91x.o 91x_scu.o main.o --no-warn-mismatch
    5. c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2/../../../../arm-elf/bin/ld.exe: ERROR: c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2\libgcc.a(_divsi3.o) uses FPA instructions, whereas skeleton_RAM.elf does not
    6. c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2/../../../../arm-elf/bin/ld.exe: failed to merge target specific data of file c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2\libgcc.a(_divsi3.o)
    7. c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2/../../../../arm-elf/bin/ld.exe: ERROR: c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2\libgcc.a(_dvmd_tls.o) uses FPA instructions, whereas skeleton_RAM.elf does not
    8. c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2/../../../../arm-elf/bin/ld.exe: failed to merge target specific data of file c:/apps2/yagarto/bin/../lib/gcc/arm-elf/4.2.2\libgcc.a(_dvmd_tls.o)
    9. collect2: ld returned 1 exit status
    10. make: *** [RAM] Error 1

    As you may already notice, I've already added the --no-warn-mismatch flag, but the problem still persisted. ?(

    Next, I examined the 91x_scu.c line by line and I found out the problem resided in the following function:

    C Source Code

    1. u32 SCU_GetPLLFreqValue(void)
    2. {
    3. u8 PLL_M;
    4. u8 PLL_N;
    5. u8 PLL_P;
    6. PLL_M = SCU->PLLCONF&0xFF;
    7. PLL_N = (SCU->PLLCONF&0xFF00)>>8;
    8. PLL_P = (SCU->PLLCONF&0x70000)>>16;
    9. if ((PLL_M>0)&&(PLL_N>0))
    10. //return (u32)(((_Main_Crystal*2)*PLL_N)/(PLL_M<<PLL_P));
    11. return 1;
    12. else return 0;
    13. }
    Display All

    The compilation error will disappear after I commented the line above (since I didn't call this function anyways). I wonder why?! @_@

    Now that I could compile successfully, I turned on J-Link GDB Server and tried to debug my project into RAM. I got the following error:

    Source Code

    1. No source file named skeleton_RAM.elf.
    2. source .gdbinit
    3. target remote localhost:2331
    4. 0x00000160 in ?? ()
    5. Cannot access memory at address 0xe24dd010
    6. monitor endian little
    7. Target endianess set to "little endian"
    8. monitor speed adaptive
    9. Select adaptive clocking instead of fixed JTAG speed
    10. monitor reset 0
    11. Resetting target (halt after reset)
    12. break main
    13. Breakpoint 1 at 0x4001180: file main.c, line 62.
    14. load
    15. Loading section .text, size 0x11f0 lma 0x4000000
    16. Remote communication error: Bad file descriptor.
    17. continue
    18. putpkt: write failed: No error.
    Display All

    I am totally stuck. All I want to do is to make use of the ST library in my project. Any help/guidance would be greatly appreciated!


    PS: soundso, did you get your VIC working already? I will eventually need interrupts in my project too.
  • Hi,
    i uploaded my example project for Yagarto here ! Everything is working excepting this interrupt problem. If it is not works at your pc, maybe theres a installation problem and your compiler use the wrong librarys during the colpilation. I think i had a similar problem because it came in conflict with a installation of an other software.
  • Hi,

    so if you want to use the ST library you have to add -mfpu=fpa to your compiler options. Then it should work (at least it was like this for me). The problem with the IRQs could be the same I had. From what i have seen you want to execute out of the RAM. The IRQ vectors have to be in ROM address 0x00000000. The RAM starts at address 0x04000000. Therefore the interrupt adresses are 0x04XXXXXX. The ARM normally supports jumps which are 24bit. That way it cannot jump from the interrupt vector table from the ROM into the RAM. It does it once or twice when stepping but then.... you know. The solution is to compile the startup code containing the IRQ vectors (or the whole project) with the option -mlong-calls. Then the ARM supports 32bit jumps which should do it.