RM48L950PGE & FreeRTOS

Update - I can get the project to build and flash using the sys_link.cmd settings from my old RM48L950ZWT project. But the application does not run when flashed. I assume that this is because the memory is set up wrong and the FreeRTOS tasks are not launching.

Any help much appreciated!!

JW

Jamie,

Good, if you copied the sections directives from your old sys_link.cmd to your new one you should build fine.

Since the parts you're targetting have the same MEMORY map (same RAM, etc) I don't think that the linker command file is the issue.

Something else is wrong - you might have missed some subtle config item in the HalCoGen screens.

When you say your program is not running - what is it doing?  (Can you connect an emulator and find out where the program is?)

Hello Anthony,

With the ZWT sys_link.cmd file added to my PGE build I get the following warnings (I think this is a problem I have had for a while!!):

"../OS_HAL_PGE/source/sys_link.cmd", line 45: warning #10068-D: no matching
   section
"../OS_HAL_PGE/source/sys_link.cmd", line 44: warning #10068-D: no matching
   section
"../OS_HAL_PGE/source/sys_link.cmd", line 51: warning #10068-D: no matching
   section
"../OS_HAL_PGE/source/sys_link.cmd", line 52: warning #10068-D: no matching
   section
"../OS_HAL_PGE/source/sys_link.cmd", line 53: warning #10068-D: no matching
   section

The sections are as follows, does this look right for an RM48L952PGE?:

SECTIONS
{
    .intvecs : {} > VECTORS
    /* FreeRTOS Kernel in protected region of Flash */
    .kernelTEXT   : { sys_startup.obj(.const)
                      os_tasks.obj (.const:.string)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<auto_init.obj> (.text)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<copy_decompress_rle.obj> (*)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<cpy_tbl.obj> (*)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<copy_zero_init.obj> (*)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<copy_decompress_none.obj> (*)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<icall32.obj> (.text)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<memset32.obj> (.text)
                      -l=rtsv7R4_T_le_v3D16_eabi.lib<memcpy32.obj> (.text)
                    } > KERNEL
    .cinit        : {} > KERNEL
    .pinit        : {} > KERNEL
    /* Rest of code to user mode flash region */
    .text         : {} > FLASH0 | FLASH1
    .const        : {} > FLASH0 | FLASH1
    /* FreeRTOS Kernel data in protected region of RAM */
    .kernelBSS    : {} > KRAM
    .kernelHEAP   : {} > RAM
    .bss          : {} > RAM
    .data         : {} > RAM

/* USER CODE BEGIN (11) */
/* USER CODE END */
}

I have 1 sec tick that I would normally see incrementing from a FreeRTOS timer callback. This is what makes me think the FreeRTOS scheduled tasks are not running.When I go online with the debugger and pause the program is always at prefetchEntry in sys_intvecs.asm.

;-------------------------------------------------------------------------------

; interrupt vectors

resetEntry
        b   _c_int00
undefEntry
        b   undefEntry
        b   vPortSWI
prefetchEntry
        b   prefetchEntry
        b   _dabort
reservedEntry
        b   reservedEntry
        ldr pc,[pc,#-0x1b0]
        ldr pc,[pc,#-0x1b0]

;-------------------------------------------------------------------------------

Does that help shed some light?

Jamie,

i noticed that you have this in your linker.cmd file.

 .kernelBSS    : {} > KRAM

Is it a typo?

Hello Henry,

I have not edited the linker.cmd file so any content is auto-generated from HALcogen. I attach both the PGE generated file that I have tried to configure for FreeRTOS and the old ZWT file that I had genertaed for the FreeRTOS demo project.

Some help on interpreting the content of both files and understanding why they differ would be much appreciated.

Thanks

Jamie

1373.ZWT.txt

6683.PGE.txt

Jamie,

KRAM is ok.   I'm not sure Henry caught the FreeRTOS part.

Henry,

The FreeRTOS projects generate a separate memory section for kernel:

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    KERNEL  (RX) : origin=0x00000020 length=0x00008000
    FLASH0  (RX) : origin=0x00008020 length=0x00177FE0
    FLASH1  (RX) : origin=0x00180000 length=0x00180000
    STACKS  (RW) : origin=0x08000000 length=0x00001500
    KRAM    (RW) : origin=0x08001500 length=0x00000800
    RAM     (RW) : origin=(0x08001500+0x00000800) length=(0x0003EB00 - 0x00000800)
   
/* USER CODE BEGIN (2) */
/* USER CODE END */
}

So KRAM is valid, not a typo :).

Jamie,

When you hit the prefetch entry,  what do these registers say (especially the ones underlined):

This might be something as simple as the MPU settings....

Jamie,

A typical reason for the prefetch abort is a double-bit ECC error. Do you enable ECC checking for the flash? If so, you do need to fill the entire available 3MB flash. Any unused flash needs to be filled with a value that could act as a trap if the CPU ever starts executing code fetched from those "unused" locations. One suggested value to use as a fill is 0xEEFF3300.

Please also make sure that you program the ECC locations along with the main program memory.

Regards, Sunil

Thanks all for your input.

I checked and I do not have the ECC check enabled.  am out of office just now so cannot go online with the debugger, I will check these things out on Friday and let you know what I find.

Jamie

Hello,

So i'm back online... here are the register entries. I have rebuilt the PGE project with a sys_link.cmd from the ZWT project.

Jamie

And the picture...

A little more information..

Stepping through the intialization it seems that the trimLPO() call is failing:

void trimLPO(void)
{

/* USER CODE BEGIN (4) */
/* USER CODE END */

    /** @b Initialize Lpo: */
    /** Load TRIM values from OTP if present else load user defined values */
    /*SAFETYMCUSW 139 S MR:13.7 <APPROVED> "Hardware status bit read check" */
    if(LPO_TRIM_VALUE != 0xFFFFU)
    {
    
        systemREG1->LPOMONCTL  = (1U << 24U)
                                | LPO_TRIM_VALUE;
    }
    else
    {

        systemREG1->LPOMONCTL     = (1U << 24U)
                                 | (16U << 8U)
                                 | 8U;
    }

I cannot step through the LPO initlisation without the prefetch error occuring.

Any info people have on LPO intilisation as a possible source of my problem is much appreciated.

Jamie

Jamie,

I'm having a hard time connecting the last two posts.   The post with the CP15 registers looks like there was a precise data abort, due to ECC, on a read from address 0x08000018.   But this really doesn't match with a problem in the LPO function - or at least I don't see how it does.   And that also should be a data abort, not a prefetch abort.

On the other hand, there's the 2nd post on the LPO ...  maybe we should run this down further next.

Would it be possible for you to assembly-step through the LPO routine and find the exact assembly instruction that causes the abort?

Please also repeat this a few times to see if it is consistently the same instruction or a different instruction.

If you find out it is the same instruction, please let us know what the instruction is, and if it's a load or store accessing memory - what the memory location being accessed is.

Also, before you hit the abort, what value is in CPSR (System mode or user mode?)

And, after you reach the prefetch abort vector, what value is in R14?

Thanks Anthony,

For the first point, if I load the program and hit run then pause the debugger I find that I have landed on the prefetchEntry with the register values shown earlier.

For the second case where I am stepping through from a CPU reset, I am dropping a breakpoint on the call to the trimLPO function. Start the debugger and then step past the breakpoint and I get the data abort. On your advice i’ve stepped through the assembly.

The dabort occurs on the first LDR instruction. This is repeatable. I have had only one instance of the dabort occurring on the second LDR instruction.

R12 is 0x0000C00F and $C$CON4 is 0x0000D940

Before the abort CPSR = 0x20001DF

Note, I can only get the dabort scenario to work when I reset the CPU from prefetch lockup that occurs on first loading and starting the debugger. Perhaps that is relevant?

I attach a word document with this text and screenshots which may make things clearer.

6574.dabort_asm_step.docx

Thanks

Jamie

Jamie Wardlaw said:

For the first point, if I load the program and hit run then pause the debugger I find that I have landed on the prefetchEntry with the register values shown earlier.

Jamie Wardlaw said:

R12 is 0x0000C00F and $C$CON4 is 0x0000D940

I was hoping to confirm that address that the instruction was trying to read,  but can't tell without also knowing what the assembly instruciton is.   Also is $C$CON4 one of the operands of this instruction that is causing the data abort.

Jamie Wardlaw said:

Before the abort CPSR = 0x20001DF

Jamie Wardlaw said:

Note, I can only get the dabort scenario to work when I reset the CPU from prefetch lockup that occurs on first loading and starting the debugger. Perhaps that is relevant?

Jamie,

The trim_LPO() function reads a location from the TI OTP sector of flash bank 0 and then programs the LPO trim control register. Do you enable MPU restrictions before calling the trim_LPO() function? If so, then you need to add the bank 0 TI OTP space in a region that is readable.

Regards, Sunil

Anthony,

The contents of the LR register when I hit the prefetch following startup is 0x593400A4

Some other points of note with this latest information

1. My laptop died over the weekend, it has taken me today to get a workstation built up to rerun these tests. I have installed CCSv5.4 now, previously I was running in CCSv5.3

2. If I run without breakpoints I will end up at a prefetch abort vector. LR value as shown above. If I step through I can get to my main() and now it seems that the prefetch is occuring when I try to start the scheduler with the call to vTaskStartScheduler(). My main function is copied below

void main(void)
{
/* USER CODE BEGIN (3) */

    /* Initialise peripheral drivers, all het to output */
    gioInit();
    hetInit();
    mibspiInit();

    /* Create the main application task */

    if (xTaskCreate(UNI_APPL_main, (const signed char *)"uni_main", configMINIMAL_STACK_SIZE, NULL, (1|portPRIVILEGE_BIT), &xTask1Handle) != pdTRUE)
        {
            /* Task could not be created */
            while(1);
        }    /* Start Scheduler */

    vTaskStartScheduler();

    /* Run forever */
    while(1);
/* USER CODE END */
}

Jamie

Jamie,

Sorry to hear about your PC problems - hate when those things happen.

It seems the link register you have captured at 0x593400A4 and the CP_15_INSTRUCTION_FAULT_ADDRESS captured in your Aug 9 12:57pm post corroborate each other.

Since that's not a valid address -- something has made the processor go into the proverbial 'weeds'.   When I've experienced this on simple programs it's usually because I didn't set the stack size large enough. 

You could either try increasing the stack sizes, as sort of a brute force way to check if the problem's related.

Or if you want to drill down, what I would do is to step into the 'vTaskStartScheduler()' and then step over each C statement till I hit then one at that level that triggers the abort.
Say this is statement 'a'.

Then I'd start over again from a CPU-Reset/System Reset, do what you need to do to get to main(), and run to statement 'a' in 'vTaskStartScheduler()'.
Then don't step over 'a' since you know this will be a problem,  instead step into it like you did originally with  'vTaskStartScheduler()'.  
Now inside the functions of statement 'a' repeat this process.   Pretty soon you'll narrow things down to the exact instruction or two triggering the abort and you will probably see the problem as obvious.     Might be stack size, might be dereferencing a null or uninitialized pointer, etc...

Anthony,

So I have tried to increase the stack size - first the user stack from 0x1000 to 0x2000 using HALcogen. Then I realised that this will have no affect as I need to overwrite my PGE sys_link.cmd with the FreeRTOSZWT version before each build. So, I edited manually the sys_link.cmd memory map to the following:

MEMORY
{
    VECTORS (X)  : origin=0x00000000 length=0x00000020
    KERNEL  (RX) : origin=0x00000020 length=0x00008000
    FLASH0  (RX) : origin=0x00008020 length=0x00177FE0
    FLASH1  (RX) : origin=0x00180000 length=0x00180000
    STACKS  (RW) : origin=0x08000000 length=0x00002500
    KRAM    (RW) : origin=0x08002500 length=0x00000800
    RAM     (RW) : origin=(0x08002500+0x00000800) length=(0x0003EB00 - 0x00000800)
    
/* USER CODE BEGIN (9) */
/* USER CODE END */
}

I expect it would be easier for me to copy my edits to the USERCODE (9) area and simply reassign the default HALcogen output rather than copying the sys_link.cmg from my ZWT builds each time.

That aside, with this increase in KRAM I do see more repeatable behaviour. I can easily break on the call to main() now which I could not do with KRAM set at 0x0001500.

It appears that the FreeRTOS scheduler successfully starts if I keep stepping through but somewhere in the scheduled task the prefetch abort occurs.

I am increasingly confused by this. Perhaps it is time to take a step back and review what I am trying to achieve:

1. I had an existing RM48950L_FreeRTOS_ZWT HALcogen build executing my application

2. For production hardware I have to migrate to the RM48952PGE package

3. I created am RM4950_PGE project in HALcogen as no RM48952 project is available. The difference in processors is clock speed only. So I changed the clock speed to 220 manually. This ensures my HAL is generated with the appropriate peripherals for my PGE packaged MCU.

4. I copied over all FreeRTOS files from my ZWT project to my PGE project

5. I copied the ZWT sys_link.cmd file to my PGE project to ensure correct memory maps for FreeRTOS

6. I build successfully

7. I get prefetch abort errors with inconsistent MCU behaviour (unable to reach breakpoints consistently without stepping through from startup)

8. I increase the stack KRAM entry

9. I can now repeatedly reach a breakpoint on main()

10. Once the FreeRTOS task is scheduled I get prefetch aborts

Quite the saga! I fear that I may have had latent memory management problems in my original ZWT targeted builds that simply did not manifest themselves as a such a critical and repeatable problem. If they were not hidden in their somewhere I cannot fathom why on migration to the new PGE package the application will not execute successfully. Do you think I have missed a key step in migration?

I could set up a screenshare if you think you would be able to dig around and uncover some information from the debugger.

Thanks in advance

Jamie

Hello Sunil,

Thanks for your reply. I will look into this but as you may see from the other postings it looks like the LPO init problems was a red herring! I assume for now that HALcogen is correctly calling the appropriate files. I have not edited any HALcogen files other than the sys_link.cmd to accomodate FreeRTOS requirements.

Jamie

Hi Jamie,

Keeping with the theme of stack sizes ....

It looks like your whole application is one task?   Is 'configMINIMAL_STACK_SIZE' big enough for your application's stack needs?

Maybe try increasing the size in this setting?

Anthony,

Correct, the application is running in a single task. However, note that I also have a number of FreeRTOS timers running (up to 10).

In the FreeRTOSconfig.h header I have changed the configMINIMAL_STACK_SIZE to 256. Same result. On launch of the scheduler the system hangs, pause the debugger and it is at the prefetch abort. The LR address is as per the previous posts.

I expect that does not help?

Jamie

Jamie,

I haven't use the FreeRTOS timers service myself before, but checking the manual,  the timer callback functions execute with the timer service task stack.

Did you configure "configTIMER_TASK_STACK_DEPTH" to something reasonable for your application?

256 still may be too small for your task stack.  It all depends on what your tasks are doing.
And, don't know if we've talked about this - if you compile with DEBUG on, the compiler will put almost every local variable on the stack as opposed to using registers where possible.  It does this to make the code easier to debug.  But that could be messing you up if your 'before' was a 'release' build and your work now on the new pinout is a debug build.

Unless you're really limited in RAM you might try setting the stack sizes large,  like 2048 or 4096 and trying out the "runtime stack checking" methods described in the FreeRTOS user's guide. 

If these suggestions don't help pls. post again and we can think through where to go next...

Hello Anthony,

Increasing the configTIMER_TASK_STACK_DEPTH to 2048 from 256 removes the prefetch abort.

However, with a timer task stack depth of 2048, the application is still not running. It appears that the FreeRTOS scheduled task is unable to start i.e. the call to vTaskStartScheduler() is unsuccessful. Stepping through this call indicates that the kernel is not started because there is not enough heap to create the idle task as per comment at lin1299 of os_tasks.c

I can increase the configTOTAL_HEAP_SIZE to 10240 with no improvement.

A couple of comments here

1. I never had these problems with the ZWT builds so I am still inclined to think that there is a very simple explanation for this.

2. I 'accidentally' rebuilt my application with the ZWT HALcogen FreeRTOS files and flashed them to my PGE production hardware. The application ran!! This is not a total surprise as I think the memory maps etc are the same and we are only using peripherals that are common to both ZWT and PGE packages. I am, therefore, inclined to think it is a subtle difference in the HALcogen files that are causing the problem.

Can you provide any comment on why number 2 would work, is there something we can do to check the HALcogen project configurations or alternatively does anyone at Ti have a working PGE+FreeRTOS example project that I could integrate my application with?

Thanks

Jamie

Hi Jamie,

Super, it sounds like this is now mainly an issue of knowing how to size the FreeRTOS stacks and heap.  

I don't really have a good answer for your #2 but:

   1) have you compared the versions of FreeRTOS between the builds?   There might be differences especially if your ZWT was based on an older HalCoGen.  The FreeRTOS version in HalCoGen isn't 'static' it does move over time.

 2) Is there a difference in the setting (Debug v.s. Release)?  that you are using to build the projects?   This would definitely impact the amount of stack that the compiler uses.

Best Regards,

Anthony

Jamie,

I was also just thinking that you probably need some FreeRTOS specific help now to understand resource usage.
There is a FAQ page http://www.freertos.org/FAQMem.html that has some information.  

There's also a support forum: http://www.freertos.org/FreeRTOS_Support_Forum_Archive/freertos_support_forum_archive_index.html

I typed 'stack usage' in the search and got  > 200 hits so this seems to be a frequent topic of discussion.

Just want to point out that those resources from the FreeRTOS community are also availalble to you especially as you get more into the RTOS itself and move away from chip questions - you might find better answers there.

Hello Anthony,

Answering your second point first - no, I do not change between debug and release. The approach I am using is to exclude my ZWT files from the build and include PGE ones. My directory structure for the project is as follows:

$project_root

$project_root\APP (this contains my application files)

$project_root\OS_HAL_PGE (this contains all HALcogen RM48L950PGE drivers and FreeRTOS for ZWT packages)

$project_root\OS_HAL_ZWT (this contains all HALcogen RM48L950ZWT_FreeRTOS drivers))

This allows me to easily exclude the files, and then only modify the project include paths to find the correct OS_HAL_PGE headers.

I have also used alternative configurations in the one project for ZWT versus PGE but I find that just excluding the directories is as fast.

On the first point, the FreeRTOS version that I use in the PGE builds is the same as from the ZWT example project in HALcogen. I have simply copied all os_ header and source files over to my OS_HAL_PGE folder.

The fact that everything runs well in the ZWT build always brings me back to thinking that I have missed something in my PGE HALcogen setup.

Jamie

Hi Jamie,

This does sound like a puzzle then.   Have you tried to *diff* the files in the two OS_HAL_pkg directories to make sure there isn't something significantly different that you're not remembering?

Otherwise, are the PLL settings for the two chips the same or is the PGE running at a lower frequency?  Maybe if its running at a lower frequency, you're getting more simultaneous events and using more stack because more things line up at the same time. 

Aside from these - I'm a bit out of ideas for now.    It really doesn't sound like you've changed anything.
And the silicon is the same between the two packages;  so that shouldn't be a variable.

Hello Anthony,

My PGE PLL settings are modified to deliver the 220MHz clock speed which as I understand it is the only difference between the RM48950's and 952's. My PLL settings are the same as for the RM48952ZWT HALcogen project defaults.

I did diff the projects before, I will do this again though to try and identify anomalies.

Jamie

Something of an update...

Diff'ing ZWT against PGE delivered nothing that jumped out as a big miss. Many of the changes appear to be for the safety package that has been developed since my earlier HALcogen builds i.e. some function renames and commenting.

I did notice that the ZWT VIM tables had an additional freeRTOS call to vPortYieldWithinAPI. I added this to my build and as expected the function did not exist in my freeRTOS OS_ files.

I then thought I should regenerate a HALcogen 3.6 RM48950ZWT_FreeRTOS project and copy in the files again to my 3.6 PGE project. vPortYieldWithinAPI is once again i nthe VIM tables but not in the source code.

 > Is the inclusion of vPortYieldWithinAPI a HALcogen error? I have removed this for now.

Also, the MCU clock speed is by default set at 100000000Hz in ZWT FreeRTOS builds. Should this not reflect the clock speed of the RM48L950 i.e. 200MHz?

Jamie

Jamie,

Interesting.  I don't know this for a fact, haven't studied the port much.   But a while back FreeRTOS got MPU support added.    The interrupt 21 where I see vPortYieldWithinAPI is sort of indicative of this change;  because once your tasks run in user mode they require an exception to get back to privilege mode.   The old way would have been the SWI exception but the SSI is a software triggerable IRQ from the system module and woudl do the same trick.

This really makes me suspect that you've got mixed versions of FreeRTOS but impossible to say from here...

Are there any FreeRTOS files in the 'common' folders not under your HAL folders? 

EDIT: sorry I didn't answer the 100MHz -  I tried HalCoGen 3.06 and I see 200MHz for the CPU by default for the RM48L950ZWT_FREERTOS type of project.  There are lots of 100MHz on the screen because the peripherals run at 1/2 the CPU clock but you should see the CPU itself as 200.

The reason you might see 100Mhz is as a limitation of the USB stick kits that have to fit within the power limits of the USB bus (< 500mA total, including the emulator and the hercules part) but I don't think that's the case for this particular configuration.

Hi Anthony,

No, I don't see any rtos files in the other project folders.

My reference to the clock speed was from the FreeRTOSConfig.h #define:

#define configCPU_CLOCK_HZ              ( ( unsigned portLONG ) 100000000 ) /* Timer clock. */

I assume this should be matched to the CPU clock speed which I think for the RM48L952 is 220MHZ ie.

#define configCPU_CLOCK_HZ              ( ( unsigned portLONG ) 220000000 ) /* Timer clock. */

It makes no difference either way, I still have the same issues.

I am thinking it might be time to take a step back and try to get a PGE build running a simple LED flash. Then attempt to migrate the flash to a FreeRTOS task, then add my application and then enable FreeRTOS timers. Perhaps that will help me identify the root cause. Or..as is often the case with these things..simply work!!

Hello,

I have returned to debugging this problem. It seems that I can run simple application on the PGE hardware but when I introduce FreeRTOS timers I get dabort exception on starting the timers. Note, it is only on starting the timers. Therefore I assume the timers are created and it could be a stack allocation problem.

To try and focus on the exact issue I reduced my application to

1. A single empty task

2. The task creates and launches up to 10 timers.

If I try to run more than 3 timers I get dabort errors.

If this is indicative of memory management issues can someone please help me find the root cause.

I think I have more than enough stack allocated, and I also think I have FreeRTOS configured appropriately.

My memory map is as follows, manually created because HALcogen does not supply a PGE FreeRTOS project:

    /* FreeRTOS Compatible Memory MAP, delete HALcogen generated MAP */

    VECTORS (X)  : origin=0x00000000 length=0x00000020
    KERNEL  (RX) : origin=0x00000020 length=0x00008000
    FLASH0  (RX) : origin=0x00008020 length=0x0017FFE0
    FLASH1  (RX) : origin=0x00188000 length=0x00178000
    STACKS  (RW) : origin=0x08000000 length=0x00003500
    KRAM     (RW) : origin=0x08003500 length=0x00000800
    /* RAM = 256KB - STACKS - KRAM */
    RAM     (RW) : origin=(0x08003500+0x00000800) length=0x0003AE00

I attach my FreeRTOS config header file. I allocate a significant amount memory to the heap and have stack depths equal to the FreeRTOS demo projects. In creating my application task I use the minimal stack depth. I have also tried increasing but it does not alleviate my problems. Every time I will only be able to start 2 timers?

Thoughts? Has anyone else had trouble with FreeRTOS timers in the Halcogen (3.06.0) builds?

FreeRTOSconfig.h attached.

6366.FreeRTOSConfig.h

Can you post complete Project for us to comment on the task creation using timer tasks

I've removed my small timer test from the project now and returned to debugging my main application.

The repeatable error on trying to start a timer is landing me in the custom_dabort handler

void custom_dabort(void)
{
    /* Need custom data abort handler here.
     * This data abort is not caused due to diagnostic checks of flash and TCRAM ECC logic.
     */
/* USER CODE BEGIN (42) */
/* USER CODE END */

I have stepped through the xTimerStart call on a single timer (I have 10 created running in lower priority than that of my main application task).

The call the xTimerStart follows this sequence:

 - call MPU_xTaskGetTickCount() : Successful

 - call xTimerGenericCommand()

- call xQueuGeneric Send()

- step to os_queue.c line 613 xTaskRemoveFromEventList()

- step to os_list.c in vListRemove line (pxlist->uxNuimberOfItems) --

- Processor hangs

- pause debugger and you are in dabort with no RAM of Flash errors

- step through to custom_dabort

- then in the loop of being returned to instructions in os_list.c and then back to dabort

So it seems that there is something wrong in here. I'm far from expert on this, any recommendation for debugging much appreciated

Prathap : please email jwardlaw@combustionsolutions.ca and I will send on the project for debug.

I think the priority is to check the HALcogen configuration for requirements of FreeRTOS.

Thanks

Jamie

Jamie,

The return instruction from a data abort is intentionally designed to again execute the instruction that generated the data abort. This is why you are seeing a repeated data abort. This is done so that the abort handler can take care of the cause of the abort and then continue execution.

Can you step through single assembly instructions in the os_list.c and identify the exact instruction that causes the abort? I suspect you will identify an LDR instruction (read from memory) that is pointing to an invalid location.

Regards, Sunil