CCS/EK-TM4C1294XL: UniFlash "Program Load completed succesfully", but Debug Port error?

Dear Ki-Soo Lee,

I have modified the assembly file because when I posted it yesterday there was a typo in it.

The current source code can be viewed below.

	.thumb
    .syntax unified

#define GPIO_PORT_CGC_R     0x400FE608

#define GPIO_PORTN0_DATA_R  0x40064004
#define GPIO_PORTN_DIR_R    0x40064400
#define GPIO_PORTN_DEN_R    0x4006451C

    .section .text
    	.org 0
	.weak	main
	.type	main, %function
	.global main
main:

    ldr R11, =GPIO_PORT_CGC_R
    ldr R10, [R11]
    MOV	R9,	 #0x1000
    ORR R10, R10, R9
    STR R10, [R11]

    ldr R11, =GPIO_PORTN_DIR_R
    ldr R10, [R11]
    ORR R10, #3
    STR R10, [r11]

    ldr R11, =GPIO_PORTN_DEN_R
    ldr R10, [R11]
    ORR R10, #3
    STR R10, [R11]

	ldr R11, =GPIO_PORTN0_DATA_R
    ldr R10, [R11]
    ORR R10, #3
    STR R10, [R11]

    NOP
    NOP



	.align
	.end

I have set up a project in Code Composer Studio and selected the GNU compiler.

When I flash the code the only output I get is

"CORTEX_M4_0: GEL Output:
Memory Map Initialization Complete"

And it seems there is no effect on the EK-TM4C1294XL. However, when I unplug the USB and plug it in again, the program is working!

So to test my assembly program, I need to flash it using Code Composer Studio, then unplug it and then plug it in again.

To answer your question, I have bought the EK-TM4C1294XL new as a kit, which can be seen in the 2 images below.

Code Composer Studio is not flawless, but it flashes after all ^.^

Could the issue with UniFlash be caused because I used the GNU assembler with my source code only, and no other files

like the _startup_ccs_gcc_c?

Dear Ki-Soo Lee,

Thank you for your quick reply. In the screenshot below you can view details about my version of UniFlash (keep in mind that I am using the GNU/Linux OS)

The a.out file is the assembled file from the source code that I sent earlier today.

Since the .out extension is not allowed to be uploaded on the forums, I will try a to send it through a PM.

Thanks for the file. I tried loading it via CCS. I get various Debug Port errors and such when I try running and halting. Your program is odd, everything is loaded to address 0x0 and that is the entry point. I'm not sure if this is will work.

Xhendos said:

Could the issue with UniFlash be caused because I used the GNU assembler with my source code only, and no other files

like the _startup_ccs_gcc_c?

This might be the case. I am going to move this thread to the TM4C forum. They can confirm if what you are doing is allowed.

Thanks

ki

Hi Charles,

Again much thanks for your 'terrific' assistance in aiding the T.I. rep (and my crüe)  w.r.t. - 'HW Over-sampling.'  

Poster here would surely benefit from a read of,  Joseph Yiu's excellent book:   'The Definitive Guide to the  ARM Cortex M3/M4.'    Several chapters are 'heavy' in Assembly Code - and the 'key MCU Registers' (just as you've noted here) - are nicely  illustrated - even emphasized...

First of all, thank you everyone who replied to this thread after it has been moved to the TM4C section. Every single comment has been helpful.

Charles Tsai was right. The stack pointer and reset vector must be defined so when the microcontroller boots up it checks location 0x4 and either execute or jump from there. Your link was helpful as it gave me insight in how this issue would be achieved using the GNU compiler toolchain.

cb1_mobile Thank you very much for your reference. I have the books from Jonathan W. Valvano, but they assume you have set up an environment and leaves a lot of essential assembly away.

I have bought your suggestion and will read it when it arrives.

The code that assembles and runs without problems is here, in case anyone is stuck in the future.

    .equ STACK_TOP, 0x20008000                                                                                                        
    .equ GPIO_PORT_CGC_R,   0x400FE608
    .equ GPIO_PORTN0_DATA_R,    0x40064004
    .equ GPIO_PORTN_DIR_R,  0x40064400
    .equ GPIO_PORTN_DEN_R,  0x4006451C
        
    .thumb
    .syntax unified

    .section .text
        .org 0
    .weak   start
    .type   start, %function
    .global _start

_start:
    .word STACK_TOP, start

start:

    ldr R11, =GPIO_PORT_CGC_R
    ldr R10, [R11]
    MOV R9,  #0x1000
    ORR R10, R10, R9
    STR R10, [R11]

    ldr R11, =GPIO_PORTN_DIR_R
    ldr R10, [R11]
    ORR R10, #3
    STR R10, [r11]

    ldr R11, =GPIO_PORTN_DEN_R
    ldr R10, [R11]
    ORR R10, #3
    STR R10, [R11]

    ldr R11, =GPIO_PORTN0_DATA_R
    ldr R10, [R11]
    ORR R10, #3
    STR R10, [R11]

    .align
    .end

Such quick purchase reveals 'high motivation.'      Surely vendor agents - and this 'outsider' are pleased to 'Note your success.'     (there will be 'No Living'  w/Charles now (having received TWO Awards - w/in a single thread) - at least for the next few days...)

In light of your 'commitment to ASM' - may it be asked,  'Why?'    You certainly realize that modern C compilers (even vendor supplied, limited versions) have 'narrowed the gap' between 'C' and 'ASM.'    

Long past studies revealed a 'huge DELTA' in (both:)

• Speed of Development
• Freedom from coding errors

always & only - in VAST favor of  'C.'     As a small, Tech Biz Owner - we strive to, 'Arrive to Market EARLY - when Profit Margins ARE HIGHEST - and even a small firm may, 'Gain a Crucial (even lasting - if we are lucky) 'Foot-hold.'  

ASM usage - instead - unless very tightly restricted & strategically directed - condemns  proponents to 'LATE ARRIVAL' - which yields (most always)  vastly SHRUNKEN (or zero) Profits!    And - usually 'exhausted staff' due to the far increased complexity/effort - which ASM always imposes!

Note too - if further 'ammo' is (at all) required - this Semi-Vendor - and ALL OTHERS - provide enhanced (often exclusive) SUPPORT - but for 'C' alone.     The 'ASM' train - most surely  - has 'Left the Station' ... destination unknown - yet surely  downhill...