• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 721 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Getting started with Hercules Development Kit - RM46L852ZWT

Jeremy Spiller
Prodigy 150 points
Other Parts Discussed in Thread: HALCOGEN, RM46L852
I am building a project for the Hercules Development Kit, using IAR 6.5, and started with the blinky example.
The example hangs at “while (1)” – ESM group3 error. What’s that? When I use “Set Next Statement” to skip the endless loop, it continues on to the blink function and works properly.
I then used Halcogen 3.04.00 to create the drivers, and copied the source to the project. I have more problems than before.
First, it hangs in sys_startup.c, line 350 “for(;;)” – The same ESM group3 error as above.
If I skip that (set next statement) it then hangs in system.c, line 211 “while((syustemREG1->CSVStat...” – There’s a comment about errata SYS#46 and “wait for until clocks are locked”. Why does that happen?
If I skip that (set next statement) I get a fatal error, and the debugger exits.
Sometimes it instead of the above problem, it just hangs with the PC stuck at location 0x0004.
Also, uploading the code takes a long time. Is there any way to speed up the downloading/verifying and programming flash?
Thank you,
Jeremy
  • 0
    TI__Genius 9015 points

    Hello Jeremy,

    I have forwarded your post to one of our experts.  They will respond back soon.

  • 0 in reply to John Hall
    Prodigy 150 points

    I found out why the PC sometimes gets stuck at 0x0004.  Halcogen made a function called "checkB0RAMECC".  When this function casues a 2 bit ECC error, _dabort is supposed to be called, and supposed to return.  Apparently something goes wrong, and it never makes it to _dabort.  Setting a break point in _dabaort doesn't help.  Here is a summary of the problems I'm having:

    1) Intermittently get stuck at line 350 of sys_startup.c "for(;;)" - ESM group3 error

    2) Intermittently get stuck at line 211 of system.c (see above for details)

    3) PC always gets stuck at 0x0004 in checkB0RAMECC because _dabort never gets called (when these functions are removed, I can run the blinky code)

    4) Edit/compile/debug cycle painfully slow because uploading to FLASH is very slow

    5) Errors #1 and #2 go away if I cold boot the development board every time before debugging - but I'd prefer not to have to do that

  • 0 in reply to John Hall
    Prodigy 150 points

    The PC gets stuck at 0x0004 because Halcogen uses the section name ".intvecs", and the IAR linker file uses the section name ".intvec", which caused the interrupt vector table to be located in the wrong place.

    After fixing that, checkB0RAMECC still hangs the system.  In "sys_selftest" at line 860, the RAM failure test is executed, and  _dabort  is called.  Both "ramErrorFound" and "flashErrorFound" checks are false, and the code falls through custom_dabort and then returns back to line 860, causing the RAM failure test to re-execute (forever).  It looks like the ramErrorFound check should have been true, and the intentionally caused error should have been detected and ignored.

  • 0 in reply to Jeremy Spiller
    TI__Guru**** 197356 points

    Hi Jeremy,

    IAR provides a blinky sample project. It is located in ..\IAR Systems\Embedded Workbench 6.5\arm\examples\TexasInstruments\RM46L852\Hercules\

    I can compile it without any error.

    Regards,

    QJ

  • 0 in reply to Jeremy Spiller
    TI__Genius 14205 points

    Hi Spiller

    Can you please share the HALCoGen Project ( HCG and DIL) with us.

    Regards
    Prathap

  • 0 in reply to Prathap
    Prodigy 150 points

    Problems #1 and #2 (from above) do not happen any more, and I'm not sure why.  Problem #3 is still there, and I have the code "#if 0" out so I can bypass checkB0RAMECC until that gets resolved.  I will send you my project code.  Please let me know how I should send it to you.

    There was a new problem that took me a while to resolve, that should be fixed.  The blinky example (downloaded from IAR) is configured to use ram location 0x8000000 to 0x802FFFF.  As soon as I used more than 4Kb of static RAM, the application would hang at the prefetchEntry interrupt vector (this happened before main(), while system code was clearing out the bss segment).  I saw that Halocgen has an un-used region 11 at 0x8001000 to 0x80017FF.  I changed the IAR linker file to use memory from 0x8002000 to 0x802FFFF, and the problem went away.