hi i am using an APM32F003 with Keil uVision compiler.
is a little known microcontroller but compatible with STM32.
I would like to write functions in RAM for different purposes.
I don't want to use the linker attribute to assign the function in ram,
but I want to copy a written one in flash and transfer it in RAM in run-time.
below the code I am trying to write but for now it is not working.
I think it's not possible in this way right?
static volatile uint8_t m_buffer_ram[100];
void flash_function()
{
/* Example */
LED2_ON();
}
void flash_function_end()
{
}
void call_function_in_ram()
{
uint32_t size = (uint32_t) flash_function_end - (uint32_t) flash_function;
/* clone function in RAM */
for (uint32_t i = 0; i < size; i++)
m_buffer_ram[i] = (((uint8_t*)&flash_function)[i]);
__disable_irq();
/* cast buffer to function pointer */
void(*func_ptr)(void) = (void(*)(void)) (&m_buffer_ram);
/* call function in ram */
func_ptr();
__enable_irq();
}
Eugene asked if your function is relocatable. This is very important. I have had issues in the past wherein I copied a function from flash to RAM, and the compiler used an absolute address in the "flash" based function. Therefore the code which was running in RAM jumped back into the flash. This is just one example of what might go wrong with moving code which is not relocatable.
If you have a debugger that can disassemble and also step through the compiled code for you, that would be ideal.
Note also "the busybee" pointed out that code which is adjacent in source code does is not guaranteed to be adjacent in the compiled binary, so your method of finding the size of the code is not reliable.
You can look in the map file to determine the size of the function.
I agree with the comment that you would be better off learning to have the linker do the work for you.
None of what I am saying here is new; I am just reinforcing the comments made above.
CODE
static volatile uint8_t m_buffer_ram[200];
static uint32_t m_function_size;
void flash_function(void)
{
LED2_ON();
}
void flash_function_end(void)
{
}
void test(void)
{
m_function_size = (uint32_t) flash_function_end - (uint32_t) flash_function;
/* clone function in RAM */
for (uint16_t i = 0; i < m_function_size; i++)
m_buffer_ram[i] = (((uint8_t*)&flash_function)[i]);
__disable_irq();
/* cast buffer to function pointer, +1 Thumb Code */
void(*func_ptr)(void) = (void(*)(void)) (&m_buffer_ram[1]);
/* call function in ram */
func_ptr();
__enable_irq();
}
MAP
Image Symbol Table
Symbol Name Value Ov Type Size Object(Section)
Local Symbols
.....
m_function_size 0x20000024 Data 4 test.o(.data)
m_buffer_ram 0x200001f0 Data 200 test.o(.bss)
Global Symbols
.....
flash_function 0x00000399 Thumb Code 12 test.o(i.flash_function)
flash_function_end 0x000003a9 Thumb Code 2 test.o(i.flash_function_end)
Memory Map of the image
Exec Addr Load Addr Size Type Attr Idx E Section Name Object
.....
0x00000398 0x00000398 0x00000010 Code RO 355 i.flash_function test.o
0x000003a8 0x000003a8 0x00000002 Code RO 356 i.flash_function_end test.o
DISASSEMBLE
.....
30: m_function_size = (uint32_t) flash_function_end - (uint32_t) flash_function;
31:
0x00000462 480D LDR r0,[pc,#52] ; #0x00000498
0x00000464 4A0D LDR r2,[pc,#52] ; #0x0000049C
0x00000466 4C0E LDR r4,[pc,#56] ; #0x000004A0
0x00000468 1A81 SUBS r1,r0,r2
0x0000046A 6021 STR r1,[r4,#0x00]
32: for (uint16_t i = 0; i < m_function_size; i++)
0x0000046C 2000 MOVS r0,#0x00
33: m_buffer_ram[i] = (((uint8_t*)&flash_function)[i]);
34:
0x0000046E 4B0D LDR r3,[pc,#52] ; #0x000004A4
0x00000470 2900 CMP r1,#0x00
0x00000472 D905 BLS 0x00000480
33: m_buffer_ram[i] = (((uint8_t*)&flash_function)[i]);
0x00000474 5C15 LDRB r5,[r2,r0]
0x00000476 541D STRB r5,[r3,r0]
32: for (uint16_t i = 0; i < m_function_size; i++)
0x00000478 1C40 ADDS r0,r0,#1
0x0000047A B280 UXTH r0,r0
32: for (uint16_t i = 0; i < m_function_size; i++)
0x0000047C 4288 CMP r0,r1
0x0000047E D3F9 BCC 0x00000474
35: __disable_irq();
36:
0x00000480 B672 CPSID I
37: void(*func_ptr)(void) = (void(*)(void)) (&m_buffer_ram[1]);
0x00000482 1C5B ADDS r3,r3,#1
38: func_ptr();
39:
0x00000484 4798 BLX r3
40: __enable_irq();
41:
0x00000486 B662 CPSIE I
I report all the information that I was able to recover.
I added a shift for the Thumb Code; the calculation of the function size coincides with the MAP file
my doubt is that in debug the pointer cannot jump to a point of the RAM .. for this reason I activate a led to see if (flashing code and run) this turns on without debugging.
as reported below, the read values coincide
(0x000003a8)flash_function_end - (0x00000398)flash_function = 0x10
(0x20000024)m_function_size = 0x10
func_ptr = 0x200001f1;
Related
Using Keil uVison 4 on Windows 7 I have a c project for stm32f105 that is showing very strange behaviour. I checked it up with a debugger, and after several hours error chasing I localized the error to comming from an already tested in other projects function. Which looked like that:
uint8_t can_add_filter_mask(can_t* this, uint32_t id, uint32_t id_mask, can_frm_type_t type, can_frm_type_t type_mask)
{
CAN_FilterInitTypeDef filt;
/* Empty filter available? */
if(this->filter_len >= 14)
{
return FALSE;
}
/* Select filter number */
if(this->canx == CAN1)
filt.CAN_FilterNumber = this->filter_len + 0;
else
filt.CAN_FilterNumber = this->filter_len + 14;
this->filter_len++;
...
//filt is read
CAN_FilterInit(&filt);
}
It was so that the structure filt is not changed after any of the assigments! Then I changed the dissassembly and it's the following (I'm sorry that it's a bit long):
108: uint8_t can_add_filter_mask(can_t* this, uint32_t id, uint32_t id_mask, can_frm_type_t type, can_frm_type_t type_mask)
0x08001B22 BD70 POP {r4-r6,pc}
109: {
110: CAN_FilterInitTypeDef filt;
111:
112: /* Empty filter available? */
0x08001B24 E92D41FF PUSH {r0-r8,lr}
0x08001B28 4604 MOV r4,r0
0x08001B2A 460D MOV r5,r1
0x08001B2C 4690 MOV r8,r2
0x08001B2E 461E MOV r6,r3
0x08001B30 9F0A LDR r7,[sp,#0x28]
113: if(this->filter_len >= 14)
114: {
0x08001B32 7C20 LDRB r0,[r4,#0x10]
0x08001B34 280E CMP r0,#0x0E
0x08001B36 DB03 BLT 0x08001B40
115: return FALSE;
0x08001B38 2000 MOVS r0,#0x00
151: }
152:
153: /******************************************************************************/
154: void can_clr_filter(can_t* this)
0x08001B3A B004 ADD sp,sp,#0x10
0x08001B3C E8BD81F0 POP {r4-r8,pc}
119: if(this->canx == CAN1)
0x08001B40 4970 LDR r1,[pc,#448] ; #0x08001D04
0x08001B42 6820 LDR r0,[r4,#0x00]
0x08001B44 4288 CMP r0,r1
0x08001B46 D103 BNE 0x08001B50
120: filt.CAN_FilterNumber = this->filter_len + 0;
121: else
0x08001B48 7C20 LDRB r0,[r4,#0x10]
0x08001B4A F88D000A STRB r0,[sp,#0x0A]
0x08001B4E E004 B 0x08001B5A
122: filt.CAN_FilterNumber = this->filter_len + 14;
0x08001B50 7C20 LDRB r0,[r4,#0x10]
0x08001B52 300E ADDS r0,r0,#0x0E
0x08001B54 B2C0 UXTB r0,r0
0x08001B56 F88D000A STRB r0,[sp,#0x0A]
123: this->filter_len++;
124:
125: /* Select mask mode */
0x08001B5A 7C20 LDRB r0,[r4,#0x10]
0x08001B5C 1C40 ADDS r0,r0,#1
0x08001B5E 7420 STRB r0,[r4,#0x10]
I'm not an assembly expert, neither an ARM expert, but I have been programing a bit on assembly and to me it doesn't look bad. What I noticed that was a bit strange was that in between was part of another function can_clr_filter, so it looked like the compiler was reusing some code, though any optimizations are turned off. The interesting part was that when I checked the address of the filt.CAN_FilterNumber variable, it changed after the line
0x08001B36 DB03 BLT 0x08001B40
from address 0x20002262 to address 0x20002252. So all changes were applied just somewhere else in the memory!! The problem has dissapear after I had declared the variable as static, though it's a mistery to me what actually happened... How could it be that a local variable is relocated to another address by the instruction BLT? Or could the uVision debugger show the wrong reference value by watching the &filt.CAN_FilterNumber?
Because you did no post the whole function from this fragment I can only guess:
There are only assignments to the local variable, but it is not used anywhere in your program and it is probably removed from the generated code.
Don't look for errors in the compiler. They are quite good and I have not found any (I am a very active coder). Always when someone says : "this is disassembly listing, the compiler is wrong", the mistake is done somewhere by the asker. Forget about disassembly when you debug your program. You just waste you time.
The problem was in the uVision: http://www.keil.com/support/docs/2824.htm.
uVision is doing some additional optimization so watching local variables is not reliable.
The code is a MIPS->ARM dynamic recompiler. After many times of running recompile_function(), it crashes at the condition clause of below code, though it can run this line of code without any issue during the earlier function running.
void recompile_function(){
//recompilation code
......
if (out > (u_char *)((u_char *)base_addr + (1 << TARGET_SIZE_2) - MAX_OUTPUT_BLOCK_SIZE - JUMP_TABLE_SIZE))
out = (u_char *)base_addr;
// other code
......
}
Variable out is the pointer used to write the recompiled code. base_addr always points to the original start of the allocated memory space. Variable out progresses 4 bytes each time an instruction is written, while base_addr keeps unchanged.
extern char extra_memory[33554432];
#define BASE_ADDR ((int)(&extra_memory))
void *base_addr;
u_char *out;
void new_dynarec_init()
{
protect_readwrite();
base_addr = ((int)(&extra_memory));
out = (u_char *)base_addr;
}
The error is "Unhandled exception at 0x7738EC9F (ntdll.dll) in frontend.exe: 0xC0000008: An invalid handle was specified."
This is the disassemble code around the faulting clause instruction.
#if NEW_DYNAREC == NEW_DYNAREC_ARM
__clear_cache((void *)beginning, out);
53830242 ldr r1,[r9]
53830246 add r3,r4,r5,lsl #2
5383024A mov r0,r7
5383024C str r3,[r2]
5383024E blx __clear_cache_bugfix (537D19DCh)
//cacheflush((void *)beginning,out,0);
#endif
// If we're within 256K of the end of the buffer,
// start over from the beginning. (Is 256K enough?)
if (out > (u_char *)((u_char *)base_addr + (1 << TARGET_SIZE_2) - MAX_OUTPUT_BLOCK_SIZE - JUMP_TABLE_SIZE))
53830252 mov r2,#0xAA98
53830256 movt r2,#0x5462
5383025A ldr r3,new_recompile_block+0A1E8h (53830550h)
5383025C ldr r4,[r2]
5383025E ldr r2,[r9]
53830262 add r3,r3,r4
53830264 cmp r2,r3
53830266 bls new_recompile_block+9F06h (5383026Eh)
out = (u_char *)base_addr;
53830268 mov r2,r4
5383026A str r4,[r9]
It's the line the debugger prompts me. I checked the disassemble window that also points to this line. What's more, if I choose continue, a new error will pop up and the program will crash at the code line "__fastfail" in function __report_gsfailure. The new error is "Unhandled exception at 0x53831547 (mupen64plus.dll) in frontend.exe: Stack cookie instrumentation code detected a stack-based buffer overrun". 0x53831546 is the address of code line "__fastfail".
#pragma warning(push)
#pragma warning(disable: 4100) // unreferenced formal parameter
__declspec(noreturn) void __cdecl __report_gsfailure(GSFAILURE_PARAMETER)
{
5383153C push {r0,r1}
5383153E push {r11,lr}
53831542 mov r11,sp
__fastfail(FAST_FAIL_STACK_COOKIE_CHECK_FAILURE);
53831544 movs r0,#2
53831546 __fastfail
}
// Declare stub for rangecheckfailure, since these occur often enough that the
// code bloat of setting up the parameters hurts performance
__declspec(noreturn) void __cdecl __report_rangecheckfailure()
{
53831548 push {r11,lr}
5383154C mov r11,sp
__report_securityfailure(FAST_FAIL_RANGE_CHECK_FAILURE);
5383154E movs r0,#8
53831550 bl __report_securityfailure (53831558h)
53831554 __debugbreak
The register PC = 53831546 so the execution point is __fastfail.
The error is caused by __clear_cache which is located above the crashed condition clause. Disabling that function call fixed the crash.
I have a USB device that outputs data of size of one byte, and I want to pass these bytes to FPGA component that exists on AXI bridge, FPGA and CPU are on the same chip... it's SoC FPGA Altera Cyclone V. CPU is ARM Cortex-A9. Kernel version 3.7.0.
There is a software that reads from the USB device and writes to a dump file... it works just fine. I tried to use mmap() to map the FPGA address to the virtual space and write to it from the userspace. When doing so... after say a minute, the kernel seem to crash.
I wrote a driver for my FPGA component and I passed the driver path to that software as a file, so that it writes to it, and eventually to my FPGA component, but the same result... kernel crashes again after a random time.
I also wrote a simple program that reads bytes from a local file and pass it to FPGA... this works fine either ways (using mmap() or driver module), the file passes through to the FPGA with no problems at all no matter how big is the file.
So the problem is when passing from USB device to FPGA, either using mmap() or a driver module.
Here is a sample crash message:
Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
Modules linked in: ipv6
CPU: 1 Not tainted (3.7.0 #106)
PC is at scheduler_ipi+0x8/0x4c
LR is at handle_IPI+0x10c/0x19c
pc : [<800521a0>] lr : [<800140d4>] psr: 80000193
sp : bf87ff58 ip : 8056acc8 fp : 00000000
r10: 00000000 r9 : 413fc090 r8 : 00000001
r7 : 00000000 r6 : bf87e000 r5 : 80535018 r4 : 8053eec0
r3 : 8056ac80 r2 : bf87ff58 r1 : 00000482 r0 : 00000481
Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 3f0c404a DAC: 00000015
Process swapper/1 (pid: 0, stack limit = 0xbf87e240)
Stack: (0xbf87ff58 to 0xbf880000)
ff40: 00000000 800140d4
ff60: fffec10c 8053e418 bf87ff90 fffec100 8000f6e0 8000851c 8000f708 8000f70c
ff80: 60000013 ffffffff bf87ffc4 8000e180 00000000 00000000 00000001 00000000
ffa0: bf87e000 80565688 803ddfb0 80541fc8 8000f6e0 413fc090 00000000 00000000
ffc0: 8053e9b8 bf87ffd8 8000f708 8000f70c 60000013 ffffffff 00000020 8000f894
ffe0: 3f86c06a 00000015 10c0387d 805658d8 0000406a 003d1ee8 31ca2085 5c1021c3
Code: eaffffad 80564700 e92d4800 e1a0200d (4c4c9b50)
---[ end trace 9e492cde975c41f9 ]---
Other crash messages start like:
Unable to handle kernel paging request at virtual address 2a7a4390
Internal error: Oops - bad syscall: ebcffb [#1] SMP ARM
pgd = bf318000
[2a7a4390] *pgd=00000000
And:
Internal error: Oops - undefined instruction: 0 [#2] SMP ARM
Modules linked in: ipv6
CPU: 1 Tainted: G D (3.7.0 #106)
Here is the full crash messages.
I noticed that all the crash messages I get intersect with the PC and LR locations, but actually I don't have previous experience with Linux kernel. I found similar error messages online but none of the proposed solutions worked for me.
Source Code:
This is function is called whenever a new buffer of bytes arrives from USB:
static void rtlsdr_callback(unsigned char *buf, uint32_t len, void *ctx)
{
if (ctx) {
if (do_exit)
return;
if ((bytes_to_read > 0) && (bytes_to_read < len)) {
len = bytes_to_read;
do_exit = 1;
rtlsdr_cancel_async(dev);
}
/* if (fwrite(buf, 1, len, (FILE*)ctx) != len) {
fprintf(stderr, "Short write, samples lost, exiting!\n");
rtlsdr_cancel_async(dev);
}
*/
if (fm_receiver_addr == NULL)
{
virtual_base = mmap(NULL, HPS2FPGA_SPAN, PROT_WRITE, MAP_PRIVATE, fd, HPS2FPGA_BASE);
if (virtual_base == MAP_FAILED)
{
perror("mmap");
close(fd);
exit(1);
}
fm_receiver_addr = (unsigned char*)(virtual_base + FM_DEMOD_OFFSET);
}
int i, j;
for (i = 0; i < len; i++)
{
*fm_receiver_addr = buf[i];
for (j = 0; j < 150; j++);
}
if (bytes_to_read > 0)
bytes_to_read -= len;
}
}
You see I commented fwrite() function (it's used by the original code to write to files) and replaced it with my code that writes to my FPGA component: *fm_receiver_addr = buf[i];. Before that I check the address to see if it's valid and obtain another address if it's not.
For the other way, the driver module, I wrote this code:
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/device.h>
#include <linux/platform_device.h>
#include <linux/uaccess.h>
#include <linux/ioport.h>
#include <linux/io.h>
#define HPS2FPGA_BASE 0xC0000000
#define HPS2FPGA_SPAN PAGE_SIZE
void* fm_demod_addr;
int i;
// Get a driver entry in Sysfs
static struct device_driver fm_demod_driver =
{
.name = "fm-demodulator", // Name of the driver
.bus = &platform_bus_type, // Which bus does the device exist
};
// Function that is used when we read from the file in /sys, but we won't use it
ssize_t fm_demod_read(struct device_driver* drv, char* buf)
{ return 0; }
// Function that is called when we write to the file in /sys
ssize_t fm_demod_write_sample(struct device_driver* drv, const char* buf, size_t count)
{
if (buf == NULL)
{
pr_err("Error! String must not be NULL!\n");
return -EINVAL;
}
for (i = 0; i < count; i++)
{
iowrite8(buf[i], fm_demod_addr);
}
return count;
}
// Set our module's pointers and set permissions mode
static DRIVER_ATTR(fm_demod, S_IWUSR, fm_demod_read, fm_demod_write_sample);
// Set module information
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Siraj Muhammad <sirajmuhammad#outlook.com>");
MODULE_DESCRIPTION("Driver for FPGA component 'FM Demodulator'");
static int __init fm_demod_init(void)
{
int ret;
struct resource* res;
// Register driver in kernel
ret = driver_register(&fm_demod_driver);
if (ret < 0)
return ret;
// Create file system in /sys
ret = driver_create_file(&fm_demod_driver, &driver_attr_fm_demod);
if (ret < 0)
{
driver_unregister(&fm_demod_driver);
return ret;
}
// Request exclusive access to the memory region we want to write to
res = request_mem_region(HPS2FPGA_BASE, HPS2FPGA_SPAN, "fm-demodulator");
if (res == NULL)
{
driver_remove_file(&fm_demod_driver, &driver_attr_fm_demod);
driver_unregister(&fm_demod_driver);
return -EBUSY;
}
// Map the address into virtual memory
fm_demod_addr = ioremap(HPS2FPGA_BASE, HPS2FPGA_SPAN);
if (fm_demod_addr == NULL)
{
driver_remove_file(&fm_demod_driver, &driver_attr_fm_demod);
driver_unregister(&fm_demod_driver);
release_mem_region(HPS2FPGA_BASE, HPS2FPGA_SPAN);
return -EFAULT;
}
return 0;
}
static void __exit fm_demod_exit(void)
{
// Remove file system from /sys
driver_remove_file(&fm_demod_driver, &driver_attr_fm_demod);
// Unregister the driver
driver_unregister(&fm_demod_driver);
// Release requested memory
release_mem_region(HPS2FPGA_BASE, HPS2FPGA_SPAN);
// Un-map address
iounmap(fm_demod_addr);
}
module_init(fm_demod_init);
module_exit(fm_demod_exit);
And I revert the userspace code to its original state, and pass the driver path: /sys/bus/platform/drivers/fm-demodulator/fm_demod to the userspace app to write to it.
Any thought about it?
Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
PC is at scheduler_ipi+0x8/0x4c
LR is at handle_IPI+0x10c/0x19c
pc : [<800521a0>] lr : [<800140d4>] psr: 80000193
[snip]
Code: eaffffad 80564700 e92d4800 e1a0200d (4c4c9b50)
---[ end trace 9e492cde975c41f9 ]---
No one can probably absolutely know the answer. Note: undefined instruction!
The PC is at scheduler_ipi+0x8/0x4c, this is hardcore ARM-Linux scheduling; an inter-processor interrupt. You can disassemble the 'Code:' part to help,
0: eaffffad b 0xfffffebc
4: 80564700 subshi r4, r6, r0, lsl #14
8: e92d4800 push {fp, lr}
c: e1a0200d mov r2, sp
10: 4c4c9b50 mcrrmi 11, 5, r9, ip, cr0
The crash is at the instruction mcrrmi and this appears to be non-sense. If you disassemble sched/core.o you will see the instruction sequence, but I bet that the '4c4c9b50' value is corrupt. Ie, this is not the code the compiler generated.
So the problem is when passing from USB device to FPGA, either using mmap() or a driver module.
I will use a zen move and think a little. The USB device use DMA? Your FPGA is probably also some how in control of the ARM/AXI bus. I would at least consider the possibility that the FPGA is corrupting a bus cycle and perhaps flipping address bits and causing a phycial write to kernel code space. This can happen when you use an innocent by-stander like a DMA peripheral. The ARM CPU will use cache and burst everything.
Things to check,
The code address in (brackets) is reported as the compiler produced. If not, hardware has probably corrupted things. It is hard for Linux code to do this as the kernel code pages are typically R/O.
You should also produce disassembler for any code and see what register is in effect. For instance, the (4c4c9b50) code can be found with,
printf '\x50\x9b\x4c\x4c' > arm.bin
objdump -marm -b binary -D arm.bin
You can just objdump vmlinux to find the assembler for the scheduler_ipi routine and then determine what a pointer might be. For instance, if this_rq() was in R9 and R9 is bogus, then you have a clue.
If the code is corrupt, you need a bus analyzer and/or some routine to monitor the location and report whenever it changes to try and locate the source of corruption.
I am writing the boot-up code for an ARM CPU. There is no internal RAM, but there is 1GB of DDRAM connected to the CPU, which is not directly accessible before initialisation. The code is stored in flash, initialises RAM, then copies itself and the data segment to RAM and continue execution there. My program is:
#define REG_BASE_BOOTUP 0xD0000000
#define INTER_REGS_BASE REG_BASE_BOOTUP
#define SDRAM_FTDLL_REG_DEFAULT_LEFT 0x887000
#define DRAM_BASE 0x0
#define SDRAM_FTDLL_CONFIG_LEFT_REG (DRAM_BASE+ 0x1484)
... //a lot of registers
void sdram_init() __attribute__((section(".text_sdram_init")));
void ram_init()
{
static volatile unsigned int* const sdram_ftdll_config_left_reg = (unsigned int*)(INTER_REGS_BASE + SDRAM_FTDLL_CONFIG_LEFT_REG);
... //a lot of registers assignments
*sdram_ftdll_config_left_reg = SDRAM_FTDLL_REG_DEFAULT_LEFT;
}
At the moment my program is not working correctly because the register values end up being linked to RAM, and at the moment the program tries to access them only the flash is usable.
How could I change my linker script or my program so that those values have their address in flash? Is there a way I can have those values in the text segment?
And actually are those defined values global or static data when they are declared at file scope?
Edit:
The object file is linked with the following linker script:
MEMORY
{
RAM (rw) : ORIGIN = 0x00001000, LENGTH = 12M-4K
ROM (rx) : ORIGIN = 0x007f1000, LENGTH = 60K
VECTOR (rx) : ORIGIN = 0x007f0000, LENGTH = 4K
}
SECTIONS
{
.startup :
{
KEEP((.text.vectors))
sdram_init.o(.sdram_init)
} > VECTOR
...
}
Disassembly from the register assignment:
*sdram_ftdll_config_left_reg = SDRAM_FTDLL_REG_DEFAULT_LEFT;
7f0068: e59f3204 ldr r3, [pc, #516] ; 7f0274 <sdram_init+0x254>
7f006c: e5932000 ldr r2, [r3]
7f0070: e59f3200 ldr r3, [pc, #512] ; 7f0278 <sdram_init+0x258>
7f0074: e5823000 str r3, [r2]
...
7f0274: 007f2304 .word 0x007f2304
7f0278: 00887000 .word 0x00887000
To answer your question directly -- #defined values are not stored in the program anywhere (besides possibly in debug sections). Macros are expanded at compile time as if you'd typed them out in the function, something like:
*((unsigned int *) 0xd0010000) = 0x800f800f;
The values do end up in the text segment, as part of your compiled code.
What's much more likely here is that there's something else you're doing wrong. Off the top of my head, my first guess would be that your stack isn't initialized properly, or is located in a memory region that isn't available yet.
There are a few options to solve this problem.
Use PC relative data access.
Use a custom linker script.
Use assembler.
Use PC relative data access
The trouble you have with this method is you must know details of how the compiler will generate code. #define register1 (volatile unsigned int *)0xd0010000UL is that this is being stored as a static variable which is loaded from the linked SDRAM address.
7f0068: ldr r3, [pc, #516] ; 7f0274 <sdram_init+0x254>
7f006c: ldr r2, [r3] ; !! This is a problem !!
7f0070: ldr r3, [pc, #512] ; 7f0278 <sdram_init+0x258>
7f0074: str r3, [r2]
...
7f0274: .word 0x007f2304 ; !! This memory doesn't exist.
7f0278: .word 0x00887000
You must do this,
void ram_init()
{
/* NO 'static', you can not do that. */
/* static */ volatile unsigned int* const sdram_reg =
(unsigned int*)(INTER_REGS_BASE + SDRAM_FTDLL_CONFIG_LEFT_REG);
*sdram_ftdll_config_left_reg = SDRAM_FTDLL_REG_DEFAULT_LEFT;
}
Or you may prefer to implement this in assembler as it is probably pretty obtuse as to what you can and can't do here. The main effect of the above C code is that every thing is calculated or PC relative. If you opt not to use a linker script, this must be the case. As Duskwuff points out, you also can have stack issues. If you have no ETB memory, etc, that you can use as a temporary stack then it probably best to code this in assembler.
Linker script
See gnu linker map... and many other question on using a linker script in this case. If you want specifics, you need to give actual addresses use by the processor. With this option you can annotate your function to specify which section it will live in. For instance,
void ram_init() __attribute__((section("FLASH")));
In this case, you would use the Gnu Linkers MEMORY statement and AT statements to put this code at the flash address where you desire it to run from.
Use assembler
Assembler gives you full control over memory use. You can garentee that no stack is used, that no non-PC relative code is generated and it will probably be faster to boot. Here is some table driven ARM assembler I have used for the case you describe, initializing an SDRAM controller.
/* Macro for table of register writes. */
.macro DCDGEN,type,addr,data
.long \type
.long \addr
.long \data
.endm
.set FTDLL_CONFIG_LEFT, 0xD0001484
sdram_init:
DCDGEN 4, FTDLL_CONFIG_LEFT, 0x887000
1:
init_sdram_bank:
adr r0,sdram_init
adr r1,1b
1:
/* Delay. */
mov r5,#0x100
2: subs r5,r5,#1
bne 2b
ldmia r0!, {r2,r3,r4} /* Load DCD entry. */
cmp r2,#1 /* byte? */
streqb r4,[r3] /* Store byte... */
strne r4,[r3] /* Store word. */
cmp r0,r1 /* table done? */
blo 1b
bx lr
/* Dump literal pool. */
.ltorg
Assembler has many benefits. You can also clear the bss section and setup the stack with simple routines. There are many on the Internet and I think you can probably code one yourself. The gnu ld script is also beneficial with assembler as you can ensure that sections like bss are aligned and a multiple of 4,8,etc. so that the clearing routine doesn't need special cases. Also, you will have to copy the code from flash to SDRAM after it is initialized. This is a fairly expensive/long running task and you can speed it up with some short assembler.
Today I have a little proble and I think that the origin is about the stack.
This is my problem :
I declare three user task like this :
void task1Function(void) {
print_uart0("-usertask : First task is started...\r\n");
while(1){
//syscall(1);
}
}
void task2Function(void) {
print_uart0("-usertask : Second task is running...\r\n");
//syscall(); /* To return in the kernel's mode */
while(1){
}
}
void task3Function(void) {
print_uart0("-usertask : Third task is running...\r\n");
//syscall(); /* To return in the kernel's mode */
while(1){
}
}
I have an array of three task whose the strucure is below :
typedef struct
{
unsigned int *sp;
unsigned int registers[12];
unsigned int lr;
unsigned int pc;
unsigned int cpsr;
unsigned int mode;
unsigned int num;
void *stack;
int stacksize;
int priority;
int state; /* Running, Ready, Waiting, Suspended */
/* Next and previous task in the queue */
struct taskstruct *qnext, *qprev;
}taskstruct;
Here the inialisation of my tasks :
void init_task(taskstruct * task, void (*function)(void) ){
task->sp = (unsigned int*)&function;
task->registers[0] = 0; // r0
task->registers[1] = 0; // r1
task->registers[2] = 0; // r2
task->registers[3] = 0; // r3
task->registers[4] = 0; // r4
task->registers[5] = 0; // r5
task->registers[6] = 0; // r6
task->registers[7] = 0; // r7
task->registers[8] = 0; // r8
task->registers[9] = 0; // r9
task->registers[10] = 0; // r10
task->registers[11] = 0; // r11
task->registers[12] = 0; // r12
task->lr = 0;
task->pc = 0;
task->cpsr = 0;
task->mode = 0x10;
}
init_task(&task[0],&task1Function);
init_task(&task[1],&task2Function);
init_task(&task[2],&task3Function);
But when I passed the task[0].sp to my activate function, it's always the last declared task that is launched (i.e the third):
.global activate
activate:
LDR r12, [r0]
/*STMFD sp!,{r1-r11,lr}*/
NOP
msr CPSR_c, #0x10 /* User mode with IRQ enabled and FIQ disabled*/
mov pc, r12
So I guess that I have a problem with my user stack and that I have to setup a different stack for each of them, am I right ? In this case, can somebody tell me how I have to proceed ?
Regards, Vincent
Yes, you are right.
You must have separate stacks for each task, since the state of the stack is part of the task's total state.
You could add something like
uint32_t stack[512];
to your taskstruct, and then set/restore the task pointer accordingly when switching tasks, of course. It's hard to provide enough detail in this context.
'Ok but how I can allocate the stack task ? ' - malloc it.
You can economize on mallocs by adding the stack space on the end of the taskstruct - all your current members are fixed-size, so calculating the total size to malloc is easy.
The hard bit with these taskers is getting the interrupt entry correct, ie. when an interrupt handler needs to change a task state and so has to exit via the scheduler. This is especially good fun with nested interrupts. Good luck with that!