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.

Blue Screen with Blinky Project

Other Parts Discussed in Thread: HALCOGEN, RM48L950

I wanted to check out the halcogen Blinky example on the Hercules USB stick.
Halcogen was ok, a new CCS Blinky project compiled ok.

As target I selected the TI XDS100v2 USB Emulator with "processor" EVMDRX45X.
The debugger is not able to stop the processor, no download takes place.
After choosing "continue launching" the debugger shows an active stop button.
Hitting the debugger stop button crashes windows.

When I select RM48L950 as processor flashing the program seems to work but takes more than 2 minutes to complete.
Hitting the debugger stop button crashes windows.
                                                       

How can I get this simple program running on the stick?

After these trials I wanted to check the Hercules Safety MCU Demos again. The demo software couldn't be detected

any more on the chip. Programming the software couldn't be done due to the missing nowFlash tool. But nowFlash

is definitely installed

                                                            

  • Do you use windows 7 or higher?

    I have seen that the safety MCU demo accidentally have some issue in the registry to automatically call the nowFlash with a window 7 machine.

    But you can launch nowFlash and program it yourself.

    To save the time to download the code to flash, please:

    1. Connect to the device in CCS

    2.Click tools -> On Chip flash

    3. in the onchip flash window, click "Necessary sectors Only" and then " Remember my settings"

    By doing this, the ccs will not erase and program all the 3Megabyte flash. Save time, work better.

    Let me know if you have more questions about the blinky led example.

    Regards,

    Haixiao

     

  • Connecting to the device must be done in debug mode, that is : the debug stop button is active again and
    I'm not going to hit it now !
    Under tools there is no entry On Chip Flash. Maybe because the target is not connected.
    "Connect Target" ends up in :
    Warning:
    (Error -2062 @ 0x34BC)
    Unable to halt device. Reset the device, and retry the operation. If error persists, confirm configuration,
    power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK).
    (Release 5.0.429.0)

    I tried nowFlash. It stops with a manufacturer-ID-error even when I run the blank check only.

  • Sounds like there are some problem in the JTAG path.

    Can you publish the DOS screen shot of the NowFlash? (Please check the "keep window" to keep the information)

    Regards,

    Haixiao

  • Thanks for the hint "keep window" as there is no help joint to the help button and no helpfile in the folder.

    The JTAG-LED is lit twice for about one second while you can hear a very soft humming from the board.

    You see the white field in nowFlash ? This appears when you focus another window and come back to

    nowFlash. NowFlash must then be killed by windows, you can't close it normally.

    Regards

    Detlef

  • Please change the CPU Family from CORTEX_RXX to CORTEX_RXX_LE, this device (RMxxx) is a little endian device.

    If you have already programmed big endian code to it, the MCU might be damanged.

    Try to recover it using following method:

    1. Press and hold on the RST button. (there are two push buttons on the USB board, one is marked as RST, another one is marked as PORRST).

    2. run nowFlash, choose "Erase" only

    3. click execute button on the nowFlash win. wait until the follow window shows up (two or three dots '.' after the "connect")

    4. Release the RST button.

    5. wait...   If error message show up and the error message say sth like 'frequency match', adjust the frequency in the nowFlash win and click the execute button again (do not press the RST or PORRST).

    If other message show up, re-try step 1-5 a couple times.

    6. If the flash is sucessfully erased, then you should be able to connect to the MCU and program the new code.

    Regards,

    Haixiao

  • Haixiao,

    thanks for this, I can use the demo again (except the temperature module, which is fixed at 25°. Don't care)

    Now we are where we started.
    The bluescreen might be cured: I setup a default debug target and could use
    the stop button without a crash. But it's not finally tested.

    Still CCS is "Unable to halt device" :

  • Can you publish your  target configuration window? Here it shows ARM9 in the pic you posted. Our device is a Cortex R4F core.

    Regards,

    Haixiao

  • Haixiao,

    it's like hell!

    I've been logging the results of my actions in CCS here in this reply and then again : BlueScreen.

    I set both target options (Blinky and Default) to the XDS100v2 and RM48L950. I had to do it twice, for at CCS-Restart,

    the default config had been reset to anything.

    The first download failed due to a memory failure (I can't explain exactly which one because I don't dare start this ugly thing now!)

    The second worked, but single stepping stopped at the end of the loader (why not at "main" ?).

    I closed the debug session and started a new one.

    CCS tried to erase and load again, so I hit the break button. Bad boy ! CCS looped until BlueScreen.

  • Detlef, Haixiao,

    Is the board that you are working on really "EVMDRX45X" ?

    If so,  from what I can tell the processor on the board would be Jacinto not a TMS570.   Is there a TMS570 on this board

    as a secondary processor?


    If the board only has a Jacinto 1 DDR device, then it would make sense that it is identified as an ARM9 since that part should be

    ARM926.  But then I'd also not expect any of the flash programming tools to work or the Hercules safety demos, since it would be a very different

    product family.  (the ARM926 class is a predecessor to the "A" series cortex and usually is running an OS like Linux or QNX)..

    Best Regards,

    Anthony

  • Anthony,


    thanks for joining in.

    First of all I'm new to TI, CCS, nowFlash, Hercules. All these commotions originate here.

    But: When I purchase a development kit I expect it to be complete and a good introduction to the topic especially for TI-newbies.
    How comes that the Hercules demos don't find the automatically installed nowFlash?
    Why isn't there any help in nowFlash, even more why should I use nowFlash in a demo at all?
    If you followed the discussion, Haixiao worried about me having killed the MCU. With a demo program !!!

    Every now and then CCS cannot work correctly with the board and causes a BlueScreen.
    That's like 20 years ago when windows crashed once a day.
    You're right, I first falsely checked the EVMDMRX45X - board. But with the correct Blinky-target selection
    RM48RL950 there had been no change. Only after changing also the default target there had been a little improvement.
    Now CCS doesn't crash with the stop button no more, it crashes only while communicating with the board.
    Why isn't this thing set correctly for the first steps?

    There also must be a path problem. When I use halcogen the files are nicely sorted inc and src. I can't use this
    in a project until all *.h - files are copied into the src folder.
    As discussed with Haixiao the use of examples doesn't work because the makefiles won't be found. So I first had to look
    for makefiles (couldn't know that they are simply called makefile). But even then they are useless because they
    include lines like "CG_TOOL_ROOT := C:/ti/ccsv5/tools/compiler/tms470_4.9.5" which is completely different to
    my installation. I even don't have ccsv5 but ccsv4. Do I have to hack makefiles for a first glance at the MCU?

    I have to decide about the use of this MCU in a new project and with the DK I just wanted to get a bit familiar with Hercules.
    In the last days I only pottered away my time and achieved nothing.


    Regards
    Detlef

    Today I had to update JAVA to Version 7.17. This seemed to improve CCS a bit because I had some contacts to the board, though 
    most of the time the connections failed. Is it true that every single stepping action takes about 2 seconds to complete?
    Now that CCS finished again with a bluescreen I would like to contact the MCU via JTAG (KEIL + ULINK).
    Do you have a schematics available so that I can disconnect the associated FTDI-Pins and connect the MCU to a JTAG pinhead?
    
    
    Regards
    Detlef

  • Hi Detlef,

    Sorry you're having such a bad experience with the RM48 USB kit;  the blue screen report is very atypical as far as I'm aware.  

    If I understand correctly then, the kit you are using is the RM48 USB Kit?   Please take a look at the quick start guide http://processors.wiki.ti.com/images/5/5c/RM48_USB_QUICK_START.pdf   which has pictures of the stick, to confirm that this is the same kit that you are working with.    I think it is based on the previous posts, but want to confirm.

    Assuming that it is the same kit, then the schematics are available here:  http://processors.wiki.ti.com/images/f/f2/RM48_USB_STICK_SCHEMATICS.pdf

    The USB stick does not have an external JTAG connector for ULINK;  the FTDI device is wired directly to the JTAG pins on the RM48 microcontroller.  

    We do have other RM48 kits that support an external JTAG emulator, these would be the HDK (http://processors.wiki.ti.com/index.php/RM42_HDK_Kit)and the Control Card (http://processors.wiki.ti.com/index.php/RM48_CNCD)   The Control cards cost less, but the external JTAG connector is the TI 14-pin type so you would need an adapter to use a ULINK emulator.     The HDK costs more,  but it has an ARM-20 pin style JTAG connector so a ULINK should connect without an adapter.  With these kits, you wouldn't need to do any cutting / jumpering in order to use an external JTAG emulator.

    Note that the USB kit also gets power from the USB connector, so if you use an external emulator you will also need to provide power to the kit.

    It might make sense to try upgrading to CCSv5 first, since there has been work done to improve the performance of the XDS100v2 on ARM targets going from CCSv4 to CCSv5.  You can download CCSv5 from: http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5   There isn't a huge learning curve going from CCSv5 from CCSv4,  but there are some helpful tips tips on migration and a quick start on the CCSv5 wiki page:  http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5

    You can also increase the download speed for small programs by instructing CCS to only erase the portions of the flash needed for the .out file, instead of the entire flash.   To do this,  you should be in the "Debug" perspective and you should have launched a connection to the RM48 device (although you don't need to connect).   From this point, you can select "Tools->On Chip Flash" and change the Erase Option from "Entire Flash"  to "Necessary Sectors Only (for Program Load)".  For a small programs like the demos,  it is a lot faster this way since you might erase a few hundred kilobytes instead of 2-3 Megabytes.

    If and when you're ready to step up to something faster there is a list of emulators here:  http://processors.wiki.ti.com/index.php/Category:Emulation but you will also need to purchase a CCS license to use one of these faster emulators.    The new XDS200 class might be a good combination of price/performance if price is important. 

    Regarding HalCoGen inside a CCS project, you shouldn't need to copy the .h files from the include to src folder.    Instead, you should be able to just add the path to the include subdirectory to the compiler include path.   For example, I have a project where I'm generating the halcogen executables inside a folder 'hcg' under the ccs project.   So, I've added an entry in the "Include Options" of the compiler  "${workspace_loc:/${ProjName}/hcg/include}"   You can use the "+" icon to add an entry to the include search path, and select 'Workspace", and CCS will automatically put in the variables workspace_loc and ProjName for you...  this way you don't need to remember what these variable are but you still get the benefit of making your project more portable.    There are more tips here:  http://processors.wiki.ti.com/index.php/Portable_Projects  for project portability.

    Regarding the issue with the compiler path "CG_TOOL_ROOT := C:/ti/ccsv5/tools/compiler/tms470_4.9.5"  were you trying to build from inside the CCS IDE?   I think you can just change the compiler version from the "CCS General" tab of the project properties screen  (right click on your project name, then select "Properties").  [This is where it is on CCSv5, sorry I don't have CCSv4 installed]...    The makefiles should be regenerated for you so you don't have to edit them yourself.

    Regarding the blue screen issue,  I don't know what to suggest exactly, since in my experince the only times I've had CCS crash are when I power off my EVM while the connection is up.   And even then, it tends to just throw error messages in the console rather than blue-screen.   Actually I don't think I've ever seen a blue-screen with CCS 4 or 5.     I would ask if you are using a laptop to power the USB stick, or an unpowered hub.   If so you might try a powered hub;  just in case the issue is power related.  

    Anyway, that's a lot to process I'm sure.  And there is definitely a learning curve with a tool as complex & powerful as CCS even though we do try to make it easy.

    Please see if any of these suggestions help, and do post again to let us know where you are.   I'm sure we can get you through the issues you're seeing.

    Best Regards,

    Anthony

      

  • Hi Anthony,

    thanks for this detailed and useful reply.
    Yes, it is the RM48 USB Development Kit and yes, I'm aware that a powerful program needs more than a glance to get a grip on it.
    I'm just disappointed to have a useless DK when the program tends to crash now and then.
    I'm going to take a shortcut and use my well known Keil MDK for there is not enough time for crawling through all these sophisticated tools.

    Best Regards

    Detlef
  • Hi Detlef,

    Understand;  I'm not sure it'll be any easier for you though to try the Keil toolchain given you have the USB stick.

    I'd hate to see you start cutting into the USB stick and then wind up with a kit that's both crashing *and* a brick.   I don't know how comfortable you are w. the fine pitch SMDs that you would need to hack into in order to wire a JTAG header for uLINK into the USB stick.     I do know that while I'd be tempted, I probably wouldn't do this myself.

    If you need to go w. the Keil MDK for time reasons, I'd suggest pretty strongly getting one of the other kits (CNCD or HDK) that has a JTAG header on it already.

    How about the powered hub suggestion?  I think that could be worth a try unless you're sure there's no issue with power.

    Best Regards,

    Anthony

  • Hi Anthony,

    for your convenience  :-)  I will check the power issue, though the demo software is able to communicate with the board which is

    directly connected to a laptop.

    I didn't have a look at the schematics yet but as long as the routes don't change layers underneath the FTDI chip

    it shouldn't be a big deal. For me the most important thing is to get away from CCS to Keil so I can rely on

    a well known tool while exploring something new (even if I have to purchase a board that fits better than this USB stick).

    It's like unless you don't know how to handle a scope you shouldn't start searching signals in a TV set.

    Best Regards

    Detlef