• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 30 subscribers
  • Views 790 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.

CCS5 Debug issues: One or more sections of your program falls into a memory region that is not writable

Nikolaj K
Prodigy 65 points
Other Parts Discussed in Thread: RM48L950, HALCOGEN

Hi, 

We're evaluating the RM48 USB stick (TMDSRM48USB), and we're having some issues debugging the target reliably.

Short story:

I can start a debugging session and everything is OK, if I then terminate the debugging session, and then click the debug button again, I some times get the error:

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.

Now I've searched the forum and seen that others have seen this message, but I found nothing conclusive that I think relates to my case.

The longer story:

OS: Windows 7 64-Bit

CCS5:  5.5.0.00077 

HW: RM48 USB stick (TMDSRM48USB) connected to laptop though an externaly powered USB hub. I also tried a direct connection without the hub - same issue.

Debugger connection: XDS100V2

Halcogen 3.08.01 - RM48L950 Freertos project.

Steps to reproduce

Click the debug button

Console output (verbose flash debugging enabled):

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Writing Flash @ Address 0x00000000 of Length 0x00002E30
CortexR4: Erasing Flash Bank 0, Sector 0
CortexR4: Verifying Flash @ Address 0x00000000 of length 0x00002E30
CortexR4: Finish Writing Flash @ Address 0x00000000 of Length 0x00002E30
CortexR4: Writing Flash @ Address 0x00008020 of Length 0x00007FF0
CortexR4: Erasing Flash Bank 0, Sector 1
CortexR4: Erasing Flash Bank 0, Sector 2
CortexR4: Verifying Flash @ Address 0x00008020 of length 0x00007FF0
CortexR4: Finish Writing Flash @ Address 0x00008020 of Length 0x00007FF0
CortexR4: Writing Flash @ Address 0x00010010 of Length 0x00001B54
CortexR4: Verifying Flash @ Address 0x00010010 of length 0x00001B54
CortexR4: Finish Writing Flash @ Address 0x00010010 of Length 0x00001B54

Debugger window is now launched with PC at main. I then press terminate

When I've returned to the normal view I again Click the debug button.

CortexR4: GEL Output: Memory Map Setup for Flash @ Address 0x0CortexR4: Loader: One or more sections of your program falls into a memory region that is not writable. These regions will not actually be written to the target. Check your linker configuration and/or memory map.

If I then hit pause, I'm stuck in sys_intvecs.asm

undefEntry
b undefEntry <== Here
b vPortSWI

What puzzles me is that I do not change a single code line between failure and succes. 


Any hints as to what might be causing the issue?

Best regards,

Nikolaj

Edit: Added Halcogen info

  • 0
    TI__Expert 4610 points

    Hi Nikolaj,

    From what we could understand from the behaviour you mentioned, when you terminate the session, the program(in main) might force the device into some state which may cause this reconnecting problem. This is just a suspicion at this moment. To rule out this suspect, can you try placing a branch to self code ( a while(1) code ) at the start of the main and try the same experiment?

    That way, if the problem is still seen, we can try few other experiments.

    Regards,
    Praveen

  • 0 in reply to Praveen Kumar Ravichandran
    Prodigy 65 points

    Hi, 

    Actually isolating code had already been part of my own attempts at findng the root cause of the problem, however after your suggestion I went about it again and this time much more systematically. I finally found the offending code and shaved everything else of creating a minimal failing piece of code (and added a define to switch between failing and working code):

    #include "sys_common.h"
#include "FreeRTOS.h"
#include "FreeRTOSConfig.h"
#include "os_task.h"
#include "os_queue.h"
#include "stdlib.h"


static void vTestTask(void *);

void main(void)
{
	xTaskCreate(vTestTask,(const signed char *) "Test",240,NULL,2,NULL);
	vTaskStartScheduler();

	/*loop*/
	while(1);
}

//#define AVOID_CRASHING
static void vTestTask(void *pvParameters)
{
#ifdef AVOID_CRASHING
	const portTickType xDelay = 50 / portTICK_RATE_MS;
#endif

	while(1)
	{
#ifdef AVOID_CRASHING
		vTaskDelay( xDelay );
#endif
	}
}

    I have no experience in using FreeRTOS (or any RTOS) so I'm not 100% sure why my code is making the debugging fail when AVOID_CRASHING is not defined. I'm guessing that the problem might be something like when the task never blocks, the rest of the system is not being serviced?

    In any case if I could just get confirmation that the reason for the failing debugging is that my FreeRTOS example is not correctly coded, then that would be great. I can then focus on reading through the documentation on the FreeRTOS site. 

    Best regards,

    Nikolaj