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.

LAUNCHXL2-RM46: arm-none-eabi-gcc Does Not Produce Console Output using Project_1 Approach

Part Number: LAUNCHXL2-RM46
Other Parts Discussed in Thread: UNIFLASH, RM46L852, HALCOGEN

On Linux I have installed UniFlash and arm-none-eabi-gcc. I have been working without success to provide a way to prompt for input over a serial terminal using sci similar to how the Launchpad Project_1 example does through:

void sciDisplayText(sciBASE_t *sci, uint8 *text, uint32 length);

See: git.ti.com/.../master in ../Launchpad/RM/RM46L8/Project_1 I am using arm-none-eabi-gcc --version:

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 8-2019-q3-update) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]

(I also have arm-none-eabi-gcc (Arch Repository) 9.2.0 on another box -- same results)

I am using the following source, and building all of the required sources for the ...Init() functions:

#include <math.h>

#include "Application_Types.h"
#include "sys_selftest.h"
#include "sci.h"
#include "gio.h"
#include "rti.h"
#include "het.h"
#include "adc.h"

extern void sciDisplayText(sciBASE_t *sci, uint8 *text, uint32 length);

button USER1 = NONE, USER2 = NONE;
uint32  g_PotReading = 468750;

int main (void) {
    
    char *s = "Hello World!\r\n";
    gioInit();
    hetInit();
    adcInit();
    adcCalibration(adcREG1);
    rtiInit();
    sciInit();
    mibspiInit();
    
    mibspiREG3->PC0 &= 0xFFE; //CS0 is GIO
    mibspiREG3->PC1 &= 0x6FE; //CS0 is input
    mibspiREG3->PC8 |= 0x1;   //pull-up CS0

    sciDisplayText (scilinREG, (uint8*)s, 105);
    sciDisplayText (scilinREG, (uint8*)"All Done...\r\n", 105);
    
    return 0;
}

(I began with sciInit() alone and added the additional ...Init() functions one-by-one in case there was a needed definition contained that would prevent printing that would not be flagged by the compiler or linker)

I am using the following compile string:

arm-none-eabi-gcc -march=armv7-r --specs=nosys.specs --specs=nano.specs -o hello.out hello.c sci.c mibspi.c rti.c sys_vim.c esm.c sys_phantom.c support_functions.c notification.c sys_dma.c gio.c het.c adc.c -lm

The code is successfully compiled to executable:

$ file hello.out
hello.out: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped

And the flash succeeds without issue:

$ ./dslite.sh -c ~/doc/arm/ti_rm46x/RM46L852.ccxml -e /home/david/dev/src-c/tmp/arm/prj01/hello.out
Executing the following command:
> /opt/ti/uniflash_5.1.0/deskdb/content/TICloudAgent/linux/ccs_base/DebugServer/bin/DSLite flash -c /home/david/doc/arm/ti_rm46x/RM46L852.ccxml -e /home/david/dev/src-c/tmp/arm/prj01/hello.out

For more details and examples, please refer to the UniFlash Quick Start guide.

DSLite version 9.2.0.1723
Configuring Debugger (may take a few minutes on first launch)...
        Initializing Register Database...
        Initializing: IcePick
        Executing Startup Scripts: IcePick
        Initializing: Dap
        Executing Startup Scripts: Dap
        Initializing: CortexR4
        Executing Startup Scripts: CortexR4
Connecting...
CortexR4: GEL Output:   Memory Map Setup for Flash @ Address 0x0Loading Program: /home/david/dev/src-c/tmp/arm/prj01/hello.out
        Preparing ...
CortexR4: GEL Output:   Memory Map Setup for Flash @ Address 0x0 due to System Reset
        .text: 0 of 66556 at 0x94
Erasing Flash
        Erasing Bank 0, Sector 0
        Erasing Bank 0, Sector 1: 4%
        Erasing Bank 0, Sector 2: 9%
        Erasing Bank 0, Sector 3: 13%
        Erasing Bank 0, Sector 4: 18%
        Erasing Bank 0, Sector 5: 22%
        Erasing Bank 0, Sector 6: 27%
        Erasing Bank 0, Sector 7: 31%
        Erasing Bank 0, Sector 8: 36%
        Erasing Bank 0, Sector 9: 40%
        Erasing Bank 0, Sector 10: 45%
        Erasing Bank 0, Sector 11: 50%
        Erasing Bank 0, Sector 12: 54%
        Erasing Bank 0, Sector 13: 59%
        Erasing Bank 0, Sector 14: 63%
        Erasing Bank 0, Sector 15: 68%
        Erasing Bank 7, Sector 0: 77%
        Erasing Bank 7, Sector 1: 81%
        Erasing Bank 7, Sector 2: 86%
        Erasing Bank 7, Sector 3: 90%
        .text: 32748 of 66556 at 0x94: 48%
        .text: 65500 of 66556 at 0x94: 96%
        .data: 0 of 1052 at 0x20490: 98%
        Finished: 98%
CortexR4: GEL Output:   Memory Map Setup for Flash @ Address 0x0 due to System Reset
        Setting PC to entry point.: 98%
Running...
Success

However, when attached through a serial console (to /dev/ttyACM0 with comm parameters 19200 N82), no output is produced. Flashing the project1_RM46x.out executable, immediately restores the console output). So I am stumped. I have been though the source and header files to ensure my example approaches console output in the same manner -- in fact using the same code, but I must be missing something basic in the compile or link process such that the executable produced does not provide the same serial output as the Project_1 example does.

I'm open to all suggestions, but I can't see what CCS would be doing that results in a working Project_1 with output that arm-none-eabi-gcc and ld are not doing. Any help would be greatly appreciated. I have worn out ti.com (sorry) looking through examples and documentation, but have not found the missing piece.

  • Hi,

    From a pure tools standpoint, the best tip is to closely compare the compiler and linker options of the demo project and your new project - there may be a switch that is causing the code to not properly come out of reset or perhaps is being missed. Also, compare the linker scripts, especially the retain modifier on Interrupt Service Routines that prevent code from being removed. 

    That would be my main focus, since all other assistng components (terminal, Debug Probe, CCS) seem to be properly configured, otherwise the issue would happen somewhere else in your setup. 

    Obviously that, from a device/serial port configuration, I would need the help of other folks more experienced than I on the device itself. I will notify them. 

    Hope this helps,

    Rafael

    P.S. I couldn't download the demo code from the Git tree - somehow the tarball never finishes being generated - otherwise I would do the comparison here.  

  • David,

    Do you have an emulator that you can connect to this setup and check where the Program counter of the MCU is at? What is the baudrate setup ? We recommend that you use the emulator based approach to gain visibility into the code execution rather than using uniflash. We generally support TI ARM compiler with these devices due to availability of compiler qualification kit which enables users with developing functional safety application with a qualified compiler.Having said that our Halcogen/CCS tools do support GCC and IAR toolchains in addition to the TI toolchian.

    I looked at your build and I don`t see any pinmux (IO mux setup), pmm (power domain), MPU and system start ASM files that configure the MCU initial state including, boot/interrupt vectors, memory regions in MPU, cache configuration,  etc. Can you explain where this initialization is performed?  I am attaching the full log of the build for Project 1 in CCS with TI compiler so you understand, all the files that get used in the build.

    0121.project_1_build_log.txt

    Before you start creating SCI based serial project, it may help to get a baseline Hello world project with standard IO printf to confirm that the core is setup correctly and you are able to initialize the device as expected.

    Please check some other E2E posts that describe the process of using GCC tool chain on Hercules MCU platforms:

    Regards,

    Rahul

  • Rahul,

    Thank you for your reply. One thing I do note is that Project_1 code starts at 0x0 on the MCU where when I compile/load with arm-none-eabi-gcc and UniFlash my code begins at 0x94. I am not very experienced with freestanding ARM devices, but have 30 year experience with x86 (and 8086 before that...) I think you are right on the money with there being a linker/loader option that is being missed somewhere or some behind the scene optimization removing relevant code. I do have CCS installed on Windows, but I really never use Windows (not since Mandrake, then SuSE 7.0, and for the last decade Archlinux and openSuSE). I can work with it there and see more what is taking place.

    In order to actually learn the board (instead of learning a tool that operates on the board), I am trying to piece together the code necessary to invoke serial I/O piece-by-piece and boil it down to the minimum necessary. At least from the right-brained engineer in me, that seems to be what makes learning happen the quickest, (a good example and the ABI open)

    I will go back and dig further into the project files, linker scripts and the startup assembly files to see what got missed. I was under the impression (perhaps wrongly so) that if the code compiled as above without error, it would have the necessary startup files for the MCU included -- or I would expect the compile/link to fail. I have the system start ASM files files in my project directory, but I did not include those explicitly in the compile string. Let me boot windows and open CCS and see if I can find the differences -- I'll report back.  Again, thank you for your time.