0

我在 PIC18F87J11 上的串行引导加载程序有一个奇怪的问题，这个问题主要与 GOTO 指令有关。我将进一步解释，首先这是我的 HEX 文件。

:040C0000E2EFFFF030
:10FFC4000001E5EFFFF0000E956E00D08C8CA30EBF
:10FFD400016E550EE82EFED7012EFCD78C9CA30E85
:10FFE400016E550EE82EFED7012EFCD7EFD7EED7C3
:04FFF40000EF06F024
:04FFF800A0F4C0FFB2
:00000001FF

如您所见，第一个地址是0C00（第 1 行），然后它写入以下 E2EF、FFF0 和其余 FFFF，直到达到 64 个字节。换句话说，这就是我要写到内存中的内容。

Programming Flash Memory Addresses 0C00 - 0C3F  with the following 64 bytes of machine code

 EFE2  F0FF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF
 FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF
 FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF
 FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF

现在，当我在写入后从 PIC 读取程序存储器时，GOTO 指令与地址为 FFC4 的 HEX 文件的第二行不同

1537           00C00          EFE2                          GOTO 0x1FFC4 (should be 0x0FFC4)
1538           00C02          F0FF                          NOP

现在我的 HEX 文件的下几行转到以下地址，看起来像这样。 

Programming Flash Memory Addresses FFC4 - FFFF  with the following 64 bytes of machine code

 FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF  FFFF
 FFFF  FFFF  6E01  0E55  2EE8  D7FE  2E01  D7FC
 9C8C  0EA3  6E01  0E55  2EE8  D7FE  2E01  D7FC
 D7EF  D7EE  EF00  F006  F4A0  FFC0  FFFF  FFFF

这就是我在将上述数据写入程序存储器后从程序存储器中读取的内容。

           32739          0FFC4          FFFF                          NOP           
           32740          0FFC6          FFFF                          NOP           
           32741          0FFC8          FFFF                          NOP           
           32742          0FFCA          FFFF                          NOP           
           32743          0FFCC          FFFF                          NOP           
           32744          0FFCE          FFFF                          NOP           
           32745          0FFD0          FFFF                          NOP           
           32746          0FFD2          FFFF                          NOP           
           32747          0FFD4          FFFF                          NOP           
           32748          0FFD6          FFFF                          NOP           
           32749          0FFD8          6E01                          MOVWF config, ACCESS
           32750          0FFDA          0E55                          MOVLW 0x55    
           32751          0FFDC          2EE8                          DECFSZ WREG, F, ACCESS
           32752          0FFDE          D7FE                          BRA 0xFFDC    
           32753          0FFE0          2E01                          DECFSZ config, F, ACCESS
           32754          0FFE2          D7FC                          BRA 0xFFDC    
           32755          0FFE4          9C8C                          BCF LATD, 6, ACCESS
           32756          0FFE6          0EA3                          MOVLW 0xA3    
           32757          0FFE8          6E01                          MOVWF config, ACCESS
           32758          0FFEA          0E55                          MOVLW 0x55    
           32759          0FFEC          2EE8                          DECFSZ WREG, F, ACCESS
           32760          0FFEE          D7FE                          BRA 0xFFEC    
           32761          0FFF0          2E01                          DECFSZ config, F, ACCESS
           32762          0FFF2          D7FC                          BRA 0xFFEC    
           32763          0FFF4          D7EF                          BRA 0xFFD4    
           32764          0FFF6          D7EE                          BRA 0xFFD4    
           32765          0FFF8          EF00                          GOTO 0x1E0C00 
           32766          0FFFA          FF06                          NOP           
           32767          0FFFC          A0F0                          BTFSS INTCON3, 0, ACCESS
           32768          0FFFE          C0F4                          MOVFF 0xF4, TOSU

现在为什么地址00C00指向1FFC4 ( GOTO 0x1FFC4 ) 而不是0FFC4其余 HEX 文件实际写入的位置？

我真的希望我能在这里得到一些帮助，因为上周我一直在尝试解决这个问题。谢谢！

更新

我开始认为问题与应用程序代码的 hex 文件有关。我使用的 hex 文件是从教程中提到的批处理文件生成的，但是 mplab xc8 生成的 hex 文件有些不同。我将提供更多信息，希望有些东西能引起人们的注意。

这是批处理文件中写的

@echo off
set cfile=%1
set hexfile=%cfile:.c=.hex%

rem Check if the c file has been updated and needs to be compiled
FOR /F %%i IN ('DIR /B /O:D %cfile% %hexfile%') DO SET NEWEST=%%i
IF "%NEWEST%"=="%cfile%" (ECHO xc8 --chip=18F87J11 --CODEOFFSET=00c00h %cfile%
xc8 --chip=18F87J11 --CODEOFFSET=00c00h %cfile%

) ELSE ( echo No changes to %cfile% since last compiled. Skipping to download...
)

rem Only program the pic if the c file compiled successfully
FOR /F %%i IN ('DIR /B /O:D %cfile% %hexfile%') DO SET NEWEST=%%i
IF "%NEWEST%"=="%hexfile%" (echo serialprog %hexfile%
serialprog %hexfile%
)

这是批处理文件生成的十六进制文件

:040C0000E2EFFFF030
:020000040001F9   <---- I deleted this line because it didn't seem needed
:10FFC4000001E5EFFFF0000E956E00D08C8CA30EBF
:10FFD400016E550EE82EFED7012EFCD78C9CA30E85
:10FFE400016E550EE82EFED7012EFCD7EFD7EED7C3
:04FFF40000EF06F024
:04FFF800A0F4C0FFB2
:00000001FF

这是mplab xc8生成的hex文件

:100C000002EF06F0E6EFFFF0FF00FF00FF00FF003D
:020000040001F9
:10FFC000FF00FF00FF00FF00FF00FF000001E9EF5E
:10FFD000FFF0000E956E8C8CA30E016E550EE82E70
:10FFE000FED7012EFCD78C9CA30E016E550EE82E79
:0CFFF000FED7012EFCD7EFD7A0F4C0FF15
:00000001FF
4

1 回答 1

1

实际上，您确实需要这条线。

:020000040001F9   <---- I deleted this line because it didn't seem needed

我相信这可能是您问题的根源。这是英特尔 HEX 上的维基百科页面

以它为指导，我们可以解析这条记录。

: 02 00 00 04 00 01 F9

Byte count: 02 (Two bytes)
Address: 00 00 (Not used with this record type)
Record Type: 04 (Extended Linear Address Record: Allows for 32-bit addressing)
Data payload: 00 01 (For this record type: this is the high word in the address)
Checksum: F9 (0x02 + 0x04 + 0x01 + 0xF9 = 256: Valid record)

04扩展线性地址记录会修改所有后续记录，直到遇到另一个记录04。

04记录的数据有效负载0001意味着所有后续地址都应该在00010000 - 0001FFFF块中。HEX 文件中的下一行:10FFC4...不是指向，0000FFC4而是指向0001FFC4.

因此，GOTO正确格式化并正确指向0001FFC4，是引导加载程序无法识别04问题所在的记录。

于 2014-01-11T06:59:20.340 回答