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.

Halcogen generated startup

Other Parts Discussed in Thread: HALCOGEN

Hi,

I've had problem with running code without the debugger. JTAG works fine, but standalone doesn't start. Jumping to a data abort in the VFP init sequence.

Halcogen generates this in "sys_startup.c"

/* Note: stackless keyword is supported since compiler version 6.20.1 */
__stackless

void _c_int00()
{

    /* Enable VFP Unit */
    _coreEnableVfp_();
	
    /* Initialize Core Registers */
    _coreInitRegisters_();

    /* Initialize Stack Pointers */
    _coreInitStackPointer_();

I'm using IAR, note the "stackless" keyword.

But in "_coreEnableVfp_" in the "sys_core.asm" we have:

_coreEnableVfp_

        stmfd sp!, {r0}
        mrc   p15,     #0x00,      r0,       c1, c0, #0x02
        orr   r0,      r0,         #0xF00000
        mcr   p15,     #0x00,      r0,       c1, c0, #0x02
        mov   r0,      #0x40000000
        fmxr  fpexc,   r0
        ldmfd sp!, {r0}
        bx    lr

My ARM assembly is a bit rusty, but isn't this using the stack?

When analysing the Data abort, none of the stack pointers are pointing to the system RAM.

  • Further to my post above:
    This is for Halcogen generating code for a 20216.
    I also have a board with a 3137. When I setup Halcogen for the 3137, I get vastly different startup code. But despite ticking the 'enable VFP', the "_coreEnableVfp_" is never called from anywhere in the code.
  • Ian,

    This sounds like a common mistake... I think this is what happens if you do not change the name of the entry point.

    There is an appnote for HalCoGen / IAR.

    On the HalCoGen start page, make sure you click on 'IAR Application Note ... " and setup your project according to those steps.

    If that doesn't work then pls. post again - but this sounds like the entry point not being set.

  • Hi Anthony,

    Thanks for the info, but I've checked my project settings and they match with the settings recommended in that document.

    I've checked my Flash contents, at address zero there is a branch to _c_int00.

    It's the code in _c_int00 that I think is the problem. Specifically the stacks being used in the VFP init routine before they have been setup correctly.

    Regards,

    Ian.

  • Ok sorry I didn't see all the detail - must have been brain damaged yesterday.

    Yes it looks like the problem is the call to _coreEnableVfp_();

    To me it doesn't look necessary - because the code in _coreInitRegisters_();
    appears to also enable the VFP if you check the VFP enable box, before it initializes the VFP registers.

    You can confirm that your _coreInitRegisters_() function has this code:

    mrc p15, #0x00, r2, c1, c0, #0x02
    orr r2, r2, #0xF00000
    mcr p15, #0x00, r2, c1, c0, #0x02
    mov r2, #0x40000000
    fmxr fpexc, r2

    fmdrr d0, r1, r1
    fmdrr d1, r1, r1
    fmdrr d2, r1, r1
    fmdrr d3, r1, r1
    fmdrr d4, r1, r1
    fmdrr d5, r1, r1
    fmdrr d6, r1, r1
    fmdrr d7, r1, r1
    fmdrr d8, r1, r1
    fmdrr d9, r1, r1
    fmdrr d10, r1, r1
    fmdrr d11, r1, r1
    fmdrr d12, r1, r1
    fmdrr d13, r1, r1
    fmdrr d14, r1, r1
    fmdrr d15, r1, r1

    If it does I think you can just comment out the call to _coreEnableVfp_();.

    Let me know if this fixes the issue - if so I'll submit a ticket on the issue so it can be addressed in a future HCG release.
  • Hi Anthony,

    Sorry for the late reply, I've been away from the office a few days.

    I can confirm the _coreInitRegisters_() function does have the VFP init section you'd shown.

    Also, I have disabled the call to _coreEnableVFP_() and the program now starts successfully at power on.

    Thanks for your help.

    Regards,

    Ian.

  • Thanks for confirming this Ian, I filed an incident report SDOCM00122561 for this issue against HalCoGen.