This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

issue in C test


Our SoC uses Quad A53 configuration. Right now our processor driven tests are based on the assembly language. 

However, we are moving to C based methodology for obvious reasons.

We have got the basic test package from ARM and we have added tests to that for our SoC specific testing.

Existing set-up

In the assembly based testing, we have the following files in the shared directory of aarch64 directory. 


bootcode.s, isr_fiq.s, isr_irq.s, pagetable.s, stackhead.s, vectors.s

In the aarch64/gic_shared, we have one file - gic_config.s

Other than this, we have application specific tests under aarch64 directory

Other than this, there is a linker file link_asm_aarch64.ld

Essentially, the makefiles goes through the process of creating .o, .elf, .bin and .hex files

C based set-up

To get some basic thing work in C, I have created a simple 3 line code in C

The only change done in C based testing is that the makefile first compiled .c to .s and then rest of the process remains the same.

The same start-up files and linker command files are used for C based testing.

So, in the C based testing, I am able to get hex file properly generated.

I have run a test to make sure that the processor executes the program written in C.

I noticed that certain handshake between C and SV wasn't happening. So, i opened up the processor IP in the RTL and debugged it.

What I notice is that the processor does execute all the start-up routine without any issues.

When it enters the C code, one of the initial instructions is push value to the stack.

After a bit of looking around, I found that the stack push is stuck. I expect the stack push to go to the SRAM (which is part of bootmem sub-system in the SoC).

The problem is that the SRAM is placed in a specific memory location in the SoC address map while the processor is writing to some vague location.

Since this location is undefined, the SoC does not respond and the whole thing hangs.

As expected, I have to provide some directive to the linker to place the stack and heap at the SRAM location.

I am actually stuck here and not able to understand the next step.

However, I have also tried the following:

I checked the stackheap.s file and I find that it has defined space for stack and heap.

Additionally, it also has a label called stack_top. Further, bootcode.s initializes the stack using the stack_top label.

Anyway, I am not sure how to make sure that the stack is allocated at the SRAM memory address.

Next, I looked at the linker file. it has .text, .data, .bss section defined.

I dont know what to do next. Please note that we used GCC compiler chain.