C 字符串在循环中没有正确迭代

C string doesn't iterate correctly in loop

我正在尝试通过 Beaglebone Black 的 UART0 打印字符串。引导加载程序初始化 UART0,我只需要写入字符。我做了一个简单的函数

void uart_put(unsigned char c)
{
    while((UART0->LSR_r & 32) == 0);
    UART0->THR = c;     
}

从启动代码中调用了以下函数我只是在这个函数中打印字符。

#define SIZE_OF_ARRAY 7 
int c_entry(void)
{
unsigned char s_name[SIZE_OF_ARRAY] = "Hello";
unsigned char a_name[SIZE_OF_ARRAY] = {'H','e','l','l','o','[=11=]'};
unsigned int a_int[SIZE_OF_ARRAY] = {9,8,7,6,5,4};
int i = 0;
    for(i = 0; i<6; i++)
    {
      uart_put('0'+i);      /*print value of i*/
      uart_put(9);          /*print a tab*/
      uart_put(s_name[i]);  /*print char from string*/
      uart_put(9);          /*print a tab*/
      uart_put(a_name[i]);  /*print char from array*/
      uart_put(9);          /*print a tab*/
      uart_put('0'+a_int[i]);   /*print int from array*/
      uart_put('\n');
      uart_put('\r');
    }   
    while(1);
    return 0;
}

该函数作为字符数组工作正常,整数打印正确,但字符串未按应有的方式打印。

在链接描述文件中,更改:

. = 0x402F0400;

至:

. = 0x80000000;

根据 memory map for the AM335X ARM processor0x402F0400 是核心 SRAM,而 0x8000000 是 DDR2 内存。根据 TFTP 引导输出的屏幕截图,您正在 0x80000000 加载您的应用程序,但您的链接描述文件被配置为引用 0x402F04000.

的内存

反汇编原始二进制文件 download.bin 使用原始链接描述文件生成:

% arm-none-eabi-objdump -D -b binary -marm download.bin
download.bin:     file format binary

Disassembly of section .data:

00000000 <.data>:
    0:   e51fd000        ldr     sp, [pc, #-0]   ; 0x8
    4:   eb00000e        bl      0x44
    8:   402f1638        eormi   r1, pc, r8, lsr r6      ; <UNPREDICTABLE>
    c:   e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
    [removed several lines of text]
    4c:   e24dd030        sub     sp, sp, #48     ; 0x30
    50:   e300262c        movw    r2, #1580       ; 0x62c
    54:   e344202f        movt    r2, #16431      ; 0x402f
    [remainder of dump removed]

字符串从内存中复制到局部变量中。请注意,字符串副本的地址是 0x402f062cmovwmovt 命令将地址加载到寄存器中)。快速扫描省略的代码不会显示任何其他访问内存的尝试。

我无法访问 Beaglebone Black,因此无法对此进行测试。它确实解释了观察到的行为。由于程序正在从未初始化的 SRAM 中复制字符串,因此无法保证会显示什么。由于程序中没有其他访问内存的尝试,因此这是唯一的问题。

更改链接描述文件并重新构建结果略有不同 download.bin。原始链接描述文件生成的反汇编 download.bin 与我建议的更改之间的差异是:

10c10
<    8: 402f1638        eormi   r1, pc, r8, lsr r6      ; <UNPREDICTABLE>
---
>    8: 80001238        andhi   r1, r0, r8, lsr r2
28,29c28,29
<   50: e300262c        movw    r2, #1580       ; 0x62c
<   54: e344202f        movt    r2, #16431      ; 0x402f
---
>   50: e300222c        movw    r2, #556        ; 0x22c
>   54: e3482000        movt    r2, #32768      ; 0x8000

您可以清楚地看到用于复制字符串的新地址引用。不幸的是,我不确定其他更改是什么以及此更改是否会导致任何问题。

为了验证字符串在 0x8000022c,我们可以使用 xxd 转储 download.bin。输出为:

% xxd download.bin
0000000: 00d0 1fe5 0e00 00eb 3816 2f40 04b0 2de5  ........8./@..-.
0000010: 00b0 8de2 14d0 4de2 0030 a0e1 0d30 4be5  ......M..0...0K.
[... omitted lots of lines ...]
0000220: 0500 53e3 cdff ffda feff ffea 4865 6c6c  ..S.........Hell
0000230: 6f00 0000                                o...

字符串 Hello0x22c 可见。在 0x80000000 加载时,复制字符串的地址似乎是正确的。