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.
Hello e2e-community,
Today, I updated my IDE from ccs5.xx (don't know the details any more, could have been 5.1.??) to the latest Version 5.2.1.00018. I also installed the MCU SDK and the System Analyzer.
After doing this, I always get the messages:
"Cortex_M3_0: 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."
and
"C28xx_0: 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."
when I try to load a program on my Concerto Control Card. This happens when I try the MCU SDK demo project (without any changes to the example project!!) and also when I try to load my own program which worked fine with the old CCS version!
What can I do? I am a little disappointed - they tell me to update to the latest version, and after doing so, it does not work any more -.-
I hope somebody can help me - thank you very much already in advance!
Greetings,
Philipp
Phillip,
Could you pleae provide some additional details? How did you update CCS? Did you update using CCS update manager or did you do a download and separate install?
Have you tried the examples in ControlSuite for the Concerto device, and do those load correctly?
Hello!
I can confirm the issue as I ran into the same behavior last week. It seems that the fault belongs to the recent update of CCS that has been released last week.
Steps to reproduce the error:
- Import the blinky project from ”\controlSUITE\device_support\f28m35x\v150\F28M35x_examples_Dual\blinky”
- Compile with Flash-setting and open debug session for Concerto device
- Connect
- On loading the program, the messages mentioned in the first posting appear.
It is also not possible to erase the flash manually. The device is not locked and it works with older versions of CCS (also 5.2.1 but without recent updates).
After doing a complete reinstall of CCS, the flash procedure is working again. I think it is the update of the CCS NowFlash Emulators from version 5.1.0.0 to 5.2.1.0 that causes this issue.
Philipp,
In my case it wasn't possible to revert to the old version of CCS NowFlash Emulators. To resolve the problem please get the CCS5.2.1.00018_win32 offline version and reinstall CCS. Then it should work again. Please take care not to use the update version as this would (at the moment) install again the problematic version of the tool.
Best regards,
Marc
Hello,
Yes, I did the update using CCS > Help > Check for Updates.
So, I installed the offline Version, as MarcB proposed. Thanks for your advice!
Now, I can flash my device again. But at first, my program would not compile any more, then I worked that out. Then, I saw that the software versions from that offline CCS version were too old (xdctools), so my program would always reset itself. Then, I updated this, then I had problems with unresolved dependencies, and now I won't even work -
I am not sure if I will ever do a CCS update again.
Before I started that whole update process, everything worked fine.
- Philipp
Is there a resolution to this? I just had the same thing happen. What's the fix?
Same thing here. It is very frustrating to take steps backwards.
Another side effect of not being able to flash is that the Concerto specific RTSC timestamp module appears to add the concertoInit module. concertoInit seems to need to write a few bytes to flash. Even though I configure my platform to place code and data only into RAM, I can not debug anything unless I take out the Concerto specific timestamp module (which should be unrelated to concertoInit in my opinion).
I am having a good experience with the beta 5.3 with the new MCU SDK xx.1.74.
Don't try the 5.2 with the new MCU SDK xx.1.74 - I had an evil bug somewhere in the RTSC config file, CCS was always hanging very badly, I was not able to work any more.
All,
Sorry for the delayed reply, but I had a chance to look into the problem with the Flash support for Concerto disappearing after the patch update, and have identified the problem. It seems that a few files were mistakenly taken out during the update.
So for anyone that has updated their build from CCS5.1.1 using the available updates, I have attached a zip file containing the necessary files for adding the Concerto Flash functionality back into CCS.
Instructions:
1. Download the attached CCSnowFlash.zip
2. Extract into the following folder: <installDir>\ccsv5\ccs_base\CCSnowFlash\
3. Make sure that <installDir>\ccs_base\CCSnowFlash\configs\TMS320F28M35x.C28x.xml is now available.
Please try this and let me know if you experience any problems with it.
Also, we are currently discussing if we are able to issue a fix for the currently available update patch right now; but with CCS5.3 launching relatively soon, the update will probably be replaced with the one available for CCS5.3, so hopefully this issue will not continue to affect customers.
Thanks,
Ricky
Hi,
I ran into the same problem and applied the patch provided in the zip file but no luck.
Same problem occurred. I have Code Composer
Version: 5.4.0.00091 installed on my machine which is much newer than the version described above.
I also have two Concerto Control Cards and I tried with the second one and it worked without the patch.
Looking further into the Concerto Chip Revision I found that the one that does not work is XF28M36P63C2Z.
The chip version that works is XF28M36P63C2T. I couldn't find any documentation in terms of the differences between these two chip versions.
I also would like to know how to make the flash of C2Z version of the chip work.
Appreciate all the help and support.
Thanks
Muhammad,
What is the exact error message you are getting?
We did update the Concerto support in CCS to support additional revisions, so you might want to download the latest version of CCS (v6.0), and see if the XF28M36P63C2Z device is supported. Unfortunately, I don't really know the difference between the C2T and C2Z devices, so it might also make sense to start a different post in the C2000 section of the forums to try to find out the difference between the devices.
Thanks,
Ricky
Hello, Is there any solution for the above issue. I am having same problem with
CortxA8: Output: **** AM335x 15x15 EVM Initialization is Done ******************
CortxA8: 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.
Terrance,
Since the AM335x does not support integrated Flash programming, this is probably not the same problem as the original issue. Because of that, it might make sense to start a new thread to get the right visibility.
Thanks,
Ricky
I am experiencing the same problem with the Concerto and the CCSv6.1 updated!
(but not with CCsv5.5.0)
Dionisio
Hi Ricky
I installed the 6.1.0.00104 version from the scratch, a clean installation.
I have already installed the 5.5 version in the same hard disk and it works.
The message that I get when try to connect the C28 or load the code is:
Cortex_M3_0: GEL Output: Memory Map Initialization Complete
C28xx_0: GEL Output:
Memory Map Initialization Complete
C28xx_0: GEL Output:
RAM Initialization Complete
C28xx_0: 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.
C28xx_0: File Loader: Verification failed: Values at address 0x000000000013BDA2 do not match Please verify target memory and memory map.
C28xx_0: GEL: File: C:\Users\Dionisio\workspace_v6_1\Ingenia_C28\Debug\Ingenia_C28.out: a data verification error occurred, file load failed.
But I have no problems with the M3, I can connect to it and even erase and load the code to the M3.
If I connect firstly the M3 and then the C28, it works but even so I can't load the code and I get the same message of error.
Thanks
Dionisio
Figures: a) when I try to connect the C28 and the M3 remains disconnected. b) when I achieved the connection of the M3 and then the one of the C28 and I try to load the code in the C28.
Dionisio,
I am also facing the same issue as you specified with the version 6.1.0.104.
Regards,
Murali Krishna
I am having the exact same problem with Concerto F28M35H52C1. I can programming the M3 core but I get the exact same loader problem with the C28 core.
The problem started with upgrading to CCS v6.1.0.00104
Is there any fixes or work around yet?
All development on our projects here has come to crawl...
Thanks
Greg Hughes
All,
Nicholas provided a possible workaround for the problem on another thread here:
If you are able to try this out, please report back and let me know if this works for you as well. In the mean time, we are still actively looking into this problem and will provide more information on a possible fix as soon as possible.
Thanks,
Ricky
I tried the workaround from the other thread with some success.
What I did...
The board did finally program with out the gel script..
What is the purpose of the gel file??
But now im having breakpoints errors, can't reset anymore
thanks
Greg
Screenshots attached
Ricky,
For the moment, I uninstalled version 6.1 and working with 6.0.1 because I need to finish some projects.
My impression was / is the emulator cannot erase and program C28. More precisely CCS while uploading program skips erase / program step, but algorithm "thinks" the programming step was successful and go to verification step. There are some ways to force it to program C28 under CCS 6.1, I put them earlier in Michele's post.
So if C28 was successfully programmed once (by some tweaking), the verification step passes and allows go to debugging step.
The "tweaking" might break ability to program M3 or run debug on it, so it must be undone.
If C28 code was not changed after programming, and I tried to run debug session again, the "pretended programming" goes very fast and into verification step, which detects "perfect match" and allows debugging.
But if C28 program changes, the out file is not matched any more with what was programmed earlier. If programming step skipped, verification step complains and prevents starting debugging session.
I usually program device in these steps (C28 first, then M3):
1. Click on C28 project, so it becomes highlighted,
2 Press "debug" button - it compiles code and goes into debug perspective, erasing and programming C28.
3. Get out of debug session back into "Edit" or simply press "debug" button and select M3.
4 In the "edit" perspective, click on M3 project, press "debug" button - it compiles code and goes int debug perspective, erasing and programming M3.
5. When it loads, start debugging (M3 will be stuck in IPCMtoCBootControlSystem(), but WE DO NOT NEED TO CHECK OR DO SOMETHING, see further)
6. In debug window, at this moment C28 is disconnected. Note, M3 has performed C28 reset because it happens before M3 checks whether C28 is running. But, because of emulator control, C28 is not allowed to run.
7 Click on XDS100v2 USB Emulator/C28xx_0 so it gets highlighted, click small arrow down to the left of "load" button, select from drop down menu "Load Symbols" icon and C28 project (!! NOT the "Load program", it would re-erase and re-load C28 which was already programmed)
8. Click "connect to the target" button - C28 gets connected.
9. Click "Resume / run" - C28 runs. M3 sees that C28 is running now and exits from IPCMtoCBootControlSystem().
Now both cores are running and can be debugged.
Hi Ricky,
I finally had a chance to generate the logs. Attached is a log for a working flag, using CCS 6.01, and a failed flash, using 6.10.
In both cases, I do a quick build (with no changes) and then a flash using a debug configuration that loads both cores.
Other info you requested:
1. Emulator XDS100v2
2. OS: Windows 7
I hope this helps.
ccslogs.rar
All,
For anyone affected by this bug, if you still have CCS6.1 installed, can you try out the following steps to see if it fixes the problem for you?
1. Download the attached updated FlashC2000F021.dll
2. Copy the DLL to \ccsv6\ccs_base\DebugServer\bin\
3. Start CCS and try to load a Flash program to the C28 core.
We have been testing this solution Internally and have seen some success with it, but we are still in the process of validating the solution. In the mean time, I thought it might be helpful to get more people affected by this bug to try it out as well.
If you are able to test this out, please report back with your observations.
Thanks in advanced,
Ricky
Unfortunately , this dll didn't work in my case.
I got the same error when I tried to download the code to the C28.
Dionisio
I just tried it out, but it didn't work for me. I still get the same error.
I've attached the debug server log
All,
We have another updated Flash DLL ready for evaluation. Same instructions as before.
1. Download the attached updated FlashC2000F021.dll (need to remove the "6445." part of the attachment name)
6445.FlashC2000F021.dll
2. Copy the DLL to \ccsv6\ccs_base\DebugServer\bin\
3. Start CCS and try to load a Flash program to the C28 core.
If you are able to test this out, please report back with your observations.
Thanks in advanced,
Ricky
Well, it worked and the C-code in the C28 runs perfect.
Nevertheless I stil get the message:
C28xx_0: 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.
The letters are now in black, instead of red.
Thanks,
Dionisio
Happy to see progress! However, the new dll did not seem to help me at all. I attached a debug server log.
Thanks,
--Nick
Dionisio,
I ran into this a long time ago and investigated it.
Check your memory map to see if there are 8 bytes allocated at address 0x0. Normally, Arm processors have the Flash memory located here that is writable. The first 32-bit address contents are used to set up the stack pointer, and the next 32-bit address is used as the vector to jump to wherever c_int00 is located.
Concerto is different in that ROM code is placed there to jump to the internal ROM code, before branching to the vector contained at location 0x00200030 when the boot mode bits are configured to boot from flash.
Thus, you can not write these two addresses, as it is ROM. The section named .bootVecs is most likely directed to be placed at address 0x0000 in your linker script (which is what normal Arm processors would need to write to). For Concerto, this is not necessary. The warning is just a nuisance message, rather than anything actually prohibiting correct flash programming.
boot.asm contains the culprit code. This is part of the arm compiler's runtime system code. Here is the offending code in boot.asm.
.global __stack
;***************************************************************
;* DEFINE THE USER MODE STACK (DEFAULT SIZE IS 512)
;***************************************************************
__stack:.usect ".stack", 0, 4
.global _c_int00
.if __TI_TMS470_V7M__
;
; Add minimal boot vector table
;
.global __STACK_SIZE
.sect ".bootVecs"
.long __stack
.long _c_int00
.symdepend ".bootVecs", ".text"
.text
.endif
/* edited to remove a bogus comment I accidentally copied into the code */
Oh look at that. When I'm not in a rush and pay attention to what I'm doing it works just fine with the latest DLL.
Thank you so much for helping, Ricky!
Now it works!
Following the Ricky's advise, I checked out the .dll files in my compiler and I found two with similar name:
6445.FlashC2000F021.dll
FlashC2000F021.dll
I deleted the latter and renamed the former to FlashC2000F021.dll and now it works.
The problem came out when I downloaded the patched file because it came out with a wrong name: 6445.FlashC2000F021.dll, so the compiler was not using it and instead it was still using the old one.
Thanks Ricky!
Dionisio