固件升级后无法正常工作

嗨Mujeeb，
请允许我建议您使用二进制文件而不是hex文件。二进制文件不需要转换。
在附件中，您可以找到一个可以帮助您解决问题的简单示例。该示例由SPC5Studio的2个不同项目组成：
1.是一个简单的应用程序，切换LED7和LED8。已开发此应用程序以从第一个闪存块（0x0）执行。在存档文件中，我还包含了与此应用程序相关的二进制文件（out.bin）。假设此应用程序是您要更新的应用程序。
2.使用SPC5Studio串行驱动程序从串行和SPC5Studio闪存驱动程序读取二进制文件，以便从第一个块（0x0）开始编程核心闪存中的二进制文件。开发此测试应用程序以从RAM执行。
要运行此示例，请执行以下步骤：
一个。导入SPC5Studio，将其编译到你的RAM中
SPC560B发现板。
湾在PC上打开一个串行终端（我使用过TeraTerm）并将COM端口的波特率设置为38400。
C。跑过 。当你的LED7点亮时
SPC560B发现板
，通过串口发送文件（在TeraTerm中）。将把文件编程到SPC560B Discovery板的闪存中。
编程完成后，LED8将亮起。
现在，如果您移除然后重新插入供应
SPC560B发现板
，
，您应该看到LED7和LED8切换（换句话说，已经在闪存中编程并在电路板重启时执行）。
最好的祝福，
路易吉



以下为原文





Hi Mujeeb,

please, let me suggest you to use the binary file instead of the hex file. No conversions are needed with the binary file.

In attachment you can find a simple example that could help you to solve your issue. The example is composed by 2 different projects for SPC5Studio :

1.  is a simple application that toggles the LED7 and LED8. This applications has been developed to be executed from the first flash block (0x0). In the archive file I have also included the binary file (out.bin, ) related to this application. Suppose that this application is the  that you want update.

2.  is a simple  that uses the SPC5Studio serial driver to read a binary from the serial and the SPC5Studio flash driver in order to program the binary file in the core flash starting from the first block (0x0). This test applications is developed to be executed from RAM.

In order to run this example, please, make the following steps:

a. Import the  in SPC5Studio, compile it e load in the RAM of your
SPC560B Discovery board.


b. Open on your PC a serial terminal (I have used TeraTerm) and set the baud rate of the COM port to 38400.


c. Run the . When the LED7 is lighted on your
SPC560B Discovery board
, send the file  over serial (in TeraTerm ). The  will program the file  in the flash memory of your SPC560B Discovery board.

When the programming is finished, the LED8 will light.


Now, if you remove and then re-insert the supply on your
SPC560B Discovery board
,
, you should see the LED7 and LED8 toggle (in other words, the  has been programmed in the flash and is executed on the board reboot).

Best regards,


Luigi

你好
路易吉，
感谢您的快速回复，
我会尝试你提供的任何代码，请你再清楚一个疑问，正如我说我从我的bootloader应用程序写入flash，我的bootloader是应用程序是否有任何问题？，我想了解与此有任何冲突。
---
谢谢＆amp;问候，
Mujeeb。



以下为原文




Hi
Luigi,

Thanks for your quick reply,

I will try the code whatever provided by you,Can you please clear one more doubt, as i said i am writing into flash from my bootloader application,my bootloader is  and application is  is there any issue with this?,i would like to understand is there any conflict with this.

---

Thanks & Regards,

Mujeeb.

嗨Mujeeb，
我认为hex文件比二进制文件使用起来有点复杂，因为hex文件是一种ascii格式的内存转储，除了要编程的字节外，还包含编程字节的地址。因此，您应该在代码中分析hex文件，跳过地址并将字节编程到正确的地址。相反，二进制文件仅包含要编程的字节。因此，您可以轻松地读取和编程单个字节。
问候，
 
路易吉



以下为原文




Hi Mujeeb,
I think the hex file is a little bit more complicated to use than the binary file because the hex file is a sort of memory dump in ascii format that contains in addition to the bytes to be programmed also the addresses in which to program the bytes. So you should analyze in your code the hex file, skip the address and program the byte to the correct addresses. The binary file, instead, contains only the bytes to be progrmmed. So, you can read and program the single bytes in a easy way.
Regards,

Luigi

两种文件格式都以不同的方式封装写入内存的数据，但写入闪存的字节是相同的。
您应该通过查看相关文档来更好地了解文件格式。 .HEX文件很简单，使用的形式很容易通过1970年代的8位微处理器在汇编程序中处理。 .ELF文件要复杂得多。
我可能会避免使用二进制文件将.HEX文件发送到加载程序，并且X-MODEM更加强大。



以下为原文




Both file formats encapsulate the data written to memory in different ways, however the bytes written to flash are the same.
You should perhaps get a better appreciation of the file formats by reviewing the relevant documentation. The .HEX files are simple, using a form readily processed in assembler by the 8-bit micros of the 1970-1980's. The .ELF files are significantly more complex.
I would probably avoid sending .HEX files to the loader, using binary files and X-MODEM is far more robust.

嗨，
我很清楚你的上述建议。
让我解释一下我面临的类似问题。我有两个应用程序1.Bootloader 2.主要应用程序。执行从bootloader开始，然后跳转到主应用程序。
为了升级固件，我遵循以下程序：
 由于我无法成功加载.bin文件，因此我使用UDE工具加载和调试代码。因此我最初加载.elf文件。稍后在某个时刻，我试图通过UART发送升级版本的主应用程序（.bin）文件，该文件由Bootloader应用程序接收。 Bootloader通过UART接收.bin文件，并从主应用程序开始的特定地址位置写入闪存。在将主应用程序的完整.bin文件成功写入闪存后，我正在重新启动设置。现在，引导加载程序正常启动并跳转到主应用程序。
 
 由于引导加载程序最初以.elf格式加载，稍后在升级固件时.bin文件（仅主应用程序）被加载到闪存中。我怀疑，由于引导加载程序和主应用程序在升级后的格式上都有所不同，是否会因主应用程序的工作失败而产生任何问题？有必要让两个文件格式相同吗？
 请分享您宝贵的建议并帮助您解决问题。
提前致谢，
问候，
R.Santhamurthy



以下为原文




Hi,
I am clear with your above suggestions.
Let me explain the similar kind of issue I am facing. I have two applications 1.Bootloader 2. Main Application. The execution starts from bootloader later it jumps to the main application.
For upgrading the firmware I am following the below procedure:
   As I am using UDE tool to load and debug the code since I am unable to load .bin file successfully. Hence I am loading .elf files initially. Later at some instant I am trying to send the upgraded version of Main application (.bin) file through UART which is received by the Bootloader application. The Bootloader receives the .bin file through UART and writes into the flash memory from specific address location from where the main application begins. After successfully write the complete .bin file of main application into the flash, I am restarting the setup. Now the bootloader begins normally and jumps to the main application.
   
   Since the bootloader is loaded as .elf format initially, later while upgrading the firmware .bin file(only main application) is loaded into the flash. I suspect that, since the bootloader and main application both differs in the format post upgrade, does it creates any problem due to which working of main application fails?. Is is necessary to have both the files in same format?
   kindly share your valuable suggestion and help in getting the problem resolved.
Thanks in Advance,
Regards,
R.Santhamurthy

处理器执行二进制指令，它不理解.HEX或.ELF文件，这些是由工具（即编译器/链接器）生成的数据的更高级别封装。
目标是将指令写入闪存，并丢弃您可能拥有的任何/所有恶意包装。



以下为原文




The processor executes binary instructions, it doesn't understand .HEX or .ELF files, these are higher level encapsulations of the data generated by the tools (ie compiler / linker).
The goal is to write the instructions into flash, and discard any/all nefarious packaging you might have around it.

嗨，
感谢您的回复，
我的引导程序和应用程序在加载UDE时工作正常。 0x00000000到0x00010000分配给引导加载程序，应用程序从0x00010000开始，它从引导加载程序分支。
我在这里面临的问题是，我正在尝试升级从0x00010000开始的主应用程序。固件升级遵循以下流程。
电路板启动后，引导加载程序应用程序开始执行。我的booloader里面我等待5秒检查固件升级请求。如果在5秒内按下sw2，则会启动firware升级。我有PC应用程序通过UART读取和发送out.bin（工作主应用程序的out.bin）。（128字节/ TX）。 Bootloader通过UART接收数据，并从C-Flash的0x00010000位置开始写入。我能够成功写入Flash。完成升级过程后，我重新启动硬件。我观察到引导加载程序正在执行，但控件没有分支到主应用程序，它在最初使用UDE加载时工作。
我附加bootloader和主应用程序供您参考。请仔细阅读并提供解决问题的宝贵建议。
（仅供我使用SPCstudio 5.2.3版本生成和编译我的应用程序。最初使用UDE 4.2加载bootloader和主应用程序的.elf。）。
提前致谢
带着敬意，
R.Santhamurthy



以下为原文




Hi,
Thanks for your reply,
My bootloader and application working fine while loading with UDE. 0x00000000 to 0x00010000 is allocated for bootloader and the application starts from 0x00010000 which is getting branched from the bootloader.
The problem I am facing here is, I am trying to upgrade the main application which is starting from 0x00010000. The firmware upgrade follows the bellow procedure.
Once the board comes up the bootloader application starts executing. Inside my booloader I am waiting for 5sec to check  for firmware upgrade request. If the sw2 is pressed within 5 sec the firware upgrade starts. I have the PC application which reads and sends the out.bin(out.bin of working main application) through UART.(128 bytes/TX). Bootloader receives the data through UART and starts writing from the location 0x00010000 of C-Flash. I can able to write successfully into the Flash. After completing the upgrade process I restart the Hardware. I observed that the bootloader is getting executed but the control is not getting branched to main application which was working while initially loading using UDE.
I am attaching bootloader and main application for your reference. Kindly review and provide your valuable suggestion for resolving the issue.
(FYI my applications are generated and compiled using SPCstudio 5.2.3 version. Initially .elf of both bootloader and main application are loaded using UDE 4.2).
Thanks in advance
With Regards,
R.Santhamurthy

我没有时间/资源来涉及您的代码。
如果它在UDE之外工作，那么你需要在使用boot-loader时查看内存的不同之处，而这不是改变执行地址的调试器。我建议检测启动加载器，以便了解内存中看到的内容，以及它是否正在转移控制。



以下为原文




I don't have the time/resources to wade into your code.
If it works out of the UDE then you need to look at what's different in memory when it uses the boot-loader, and that is not the debugger that is changing the execution address. I'd suggest instrumenting the boot-loader so you understand what is is seeing in memory, and whether it is transferring control.

你好
R.Santhamurthy
抱歉耽搁了。
我要强调的是，Bolero B闪存不支持参考手册中规定的单库读写（第30.4.2.1节CFlash模块扇区化）：
这意味着无法从闪存执行一个引导加载程序，该引导加载程序在同一个Bank的另一个扇区中编写新的主应用程序。进行更新的唯一方法是从RAM执行更新过程。
在附件中，您可以找到为SPC5Studio（5.3）的最新版本开发的此过程的示例。
引导加载程序应用程序（SPC560Bxx_RLA用于发现的Flash测试应用程序）配置为在RAM中复制时的引导模式选项。这意味着引导加载程序的代码存储在从地址0x0开始的闪存中，但在执行开始时它将重新定位在RAM中。
主要应用程序（SPC560Bxx_RLA PIT Test Application for Discovery）设计为从地址0x10000开始执行闪存。
引导加载程序的第一步是执行倒计时5秒。在倒计时结束时，引导加载程序跳转到0x10000。如果在倒计时结束之前用户按下按钮SW2，则将开始主应用程序的更新。在这种情况下，必须通过串行提供新主应用程序的二进制映像（有关更多详细信息，请阅读引导加载程序的readme.txt文件）。
请注意：
1.在提供的引导加载程序示例中，必须使用要更新的新主应用程序的二进制文件的大小设置宏BIN_SIZE。在zip文件中，您还可以找到我用于示例的二进制文件out.bin（从应用程序SPC560Bxx_RLA PIT Test Application for Discovery的编译中获得）。
2.在跳转到主应用程序之前，必须停止引导加载程序中使用的所有外围设备（在示例中，串行和PIT）。
3.为了通过按钮SW2进行更新，请将引脚X4 [10]与引脚X1 [31]连接。这样，按钮SW2将连接到EIRQ17。因此，当按下按钮时，将执行EIRQ17回调（启动更新过程）。
问候，
路易吉



以下为原文




Hi
R.Santhamurthy

sorry for the delay.

Let me underline that the Bolero B flash memory doesn't support the Single Bank Read While Write as specified in the Reference Manual (paragraph 30.4.2.1 CFlash module sectorization):



This means that it is not possible to execute from flash a boot loader that programs a new main application in another Sector of the same Bank. The only way to make an update is to execute the update procedure from the RAM.

In attachment you can find an example of this procedure developed for the last release of SPC5Studio (5.3).

The boot loader application (SPC560Bxx_RLA Flash Test Application for Discovery) is configured with the Boot Mode option on Copy in RAM. This means that the code of the boot loader is stored in flash starting from address 0x0, but it is relocated in RAM when its execution starting.

The main application (SPC560Bxx_RLA PIT Test Application for Discovery) is designed to be executed from the flash starting from the address 0x10000.

The first step of the boot loader is the execution of a count down of 5 seconds. At the end of the count down the boot loader jump to 0x10000. If before the end of count down the user pushes the button SW2, the update of the main application will be started. In that case, the binary image of the new main application has to be provided via serial (please, for more details read the file readme.txt of the boot loader).

Please, note:

1. In the provided boot loader example the macro BIN_SIZE has to be set with the size of the binary file of the new main application that you want to update. In the zip file you can find also the binary file out.bin (obtained from the compilation of the application SPC560Bxx_RLA PIT Test Application for Discovery) that I have used for the example.

2. Before to jump to the main application, it is necessary to stop all the peripherals used in the boot loader (in the example, the serial and PIT).

3. In order to enable the update through the button SW2, please, connect the pin X4[10] with the pin X1[31]. In this way the button SW2 will be connect to the EIRQ17. So, when the button is pushed, the EIRQ17 callback (that starts the update procedure) will be executed.

Regards,

Luigi