如何在不改变硬件的情况下擦除和重新编程SPI EEPROM？

嗨，亨利，
如果你可以改变保护模式前的所有准备引脚另一种启动模式再试试这个。
当做，
隆皮



     以下为原文
  Hi Henry,
    if you can change the PMODE pins to an other boot mode then try this.
    regards,
    lumpi

嗨，亨利，
或者你可以尝试将SPI启动固件的VID PID组合添加到CyPress CysB3.NF文件中，这样就可以通过控制中心访问。
当做，
隆皮



     以下为原文
  Hi Henry,
    or otherwhise you may try to add the VID PID combination of the SPI booted firmware to cypress cyu***3.inf file so you get access through control center.
    regards,
    lumpi

谢谢Lumpi，
我知道我们可以通过改变PMODE引脚配置来改变ToubBooT模式，在我的情况下几乎是不可能的。
实际上，我已经尝试改变设备驱动程序INF文件，并重新加载设备驱动程序，它在FX2上工作，但是这个技巧似乎在FX3上不起作用。
对于FX2，在从I2CEEPROM启动设备作为定制设备之后，我仍然可以使用CyPress的特定于供应商的命令来下载固件（可以通过I2C访问EEPROM）到内部RAM。我不确定FX3是否仍然如此，因为我在FX3上做了同样的事情，但是它返回了失速，这意味着它不支持请求。但是，如果将设备枚举为FX3设备，则这些请求没有问题。
有没有其他的后门让我把固件下载到MyalRAMIN中？



     以下为原文
  Thanks Lumpi,
        I understand that we can change to USB boot mode by changing  PMODE pins config, it is almost impossible in my case.
        Actually I have already tried to change the device driver inf file, and reload the device driver, it works on FX2 , howerver this trick seems did not work on FX3.
         For FX2, after the device boot from I2C eeprom as a customized device, I can still use cypress' Vendor specific command to download firmware ( which can access eeprom via I2C) to the internal RAM. I am not sure if it is still the case for FX3, because I was doing the same thing on FX3 but it returns STALL, which means it does not support  the requests. However, if the device is enumerated as FX3 device, these requests have no problem.
        Is there other back door which let me download the firmware into the internal RAM in this case?

在FX3没有“后门”厂商请求进行固件下载如果用户固件运行。你必须实现这个由你自己到用户固件。



     以下为原文
  In the FX3 is no "backdoor" vendor request for firmware download if the user firmware is running. You have to implement this by your own into the user firmware.

嗨，亨利，
太糟糕了，克里斯是正确的上传请求只是工作如果上传固件支持它。而你在SPI闪存中的程序固件将不支持它。你成功了SPI闪存针吗？可能是您可以操纵SSN或MISO或SCK线，FX3不能加载固件。然后可以是控制中心用STD VID PID工作。
当做，
隆皮



     以下为原文
   Hi Henry,
    too bad, Chris is right the upload request just works if uploaded firmware support it. And your programmed Firmware in the SPI Flash won't support it. Have you success to te SPI flash pins? May be you can manipulate SSN or MISO or SCK line, that the FX3 can not load that firmware. Then may be control center works with std VID PID.
     
    REGARDS,
    LUMPI

这不会帮助你的板已经被烧成闪光。但是，这可能有助于防止后续董事会的这一问题。事先道歉，这有点复杂，所以你可能需要读它几次让一切都有意义。1.2.1 SDK包含Bootloader代码，在固件/Boot-FW下，支持控制中心通过USB下载固件所使用的命令。引导固件有它自己的，简单得多的SDKAPI（没有THealx等）。对于控制中心识别一个设备，它必须在驱动器.INF文件中有一个签名（对于USB下载，它看起来像是VID 0x04B4/PID 0x00 F3）。因此，问题是，如何使设备运行“真实”固件与您的定制VID/PID重命名与控制中心所需要的-并有能力取代自己的代码下载USB？你所能做的就是重新设计你的程序，使之闪存，使它由两个子程序-你的“真实”固件，和一个复制的BooToFW。SDKSH能够在“正常”SDK中的引导SDK和CYU3PUBJUBPACTUBBOOTER（）中从一个子程序转移控制到另一个子程序（参见CYFX3BOOTJOPTOPTICANCENTY（））。您将需要修改链接器脚本，以便子程序在固定内存地址（即“真正的”固件0x400万和BooToFFW的0x400 7000）开始。可以修改BooToFW项目中的描述符，使PID为0x00 F3。编译启用USBboot支持和SPIBOOT支持的项目，然后运行ARM ENO EABI Objo以将ELF转换成二进制文件：ARM无EABI Objix-输入目标＝ELF32 LITTLLAMM输出目标=二进制-在“Real'固件中所有${ProjNe}BoToFF.Bin”，您可以n使用一个简单的S文件将BooToFFW作为Blob：.Toe.To..Bug。代码32。全局BooToFFW BooToFW:：
用于“真实”固件的链接器脚本需要将BLUB放置在它编译到的相同位置（在BooToFW项目中），并使BooToFFW（合并）程序的起始地址。现在进行切换。的boot_fw可以增强有一个变量，跟踪这是否是第一次第一次开机，或不。第一次开机，代码应该叫cyfx3bootu***start（cytrue，…），似乎是一个要求开关从“真实”的固件回boot_fw。（cyu3pu***jumpbacktobooter()抛出一个错误，如果你不这样做）。的boot_fw必须负载的'真实'的固件u***descriptors（因为我们tellcyfx3bootu***start我们不想再数）。这是一个棘手的部分子程序的方法- boot_fw子程序需要访问的“真实”的子程序的描述符，所以你需要建立相应的子程序。一旦加载了boot_fw电话cyfx3bootjumptoprogramentry()描述符与“真实”的子程序的地址。重刷，你需要的信号，是时候跳回到boot_fw '真正的'固件的能力。你怎么做这是特定于应用程序的；这样会对供应商的具体要求收据。当“真实”的固件接收到这个信号从主机它关闭所有的FX3外设和电话cyu3pu***jumpbacktobooter（boot_fw）。现在BooToFW又有了控制。它检查“第一启动”的旗帜，认为这是一个重新启动。这次callscyfx3bootu***start（cyfalse）和负载的boot_fw USB描述符（现在发现它的方式与控制中心兼容的）。然后，它进入u***boot模式，根据命令控制中心。你需要做一个修改的USB启动代码在boot_fw是忽略尝试下载到boot_fw内存范围（因为这会破坏固件进行下载）。由于控制中心似乎回读写作为验证的是什么，这意味着你不能下载合并。IMG内存时（即通过SPI Flash）已经运行。但“正常”的图像，如cybootprogrammer不重叠boot_fw记忆可以被下载。这是什么让你重写Flash控制中心。什么是好的是如果柏消除这一切的需要提供一些方法来跳回到一种只支持USBboot的rombootloader（即，如果pmodestraps已为USBboot）。希望这能有所帮助，史提夫



     以下为原文
  This won't help your board that already has firmware burned to flash. But, it could help prevent this issue on subsequent boards. Apologies in advance, this gets a little convoluted, so you might have to read it a couple times for everything to make sense.

The 1.2.1 SDK includes bootloader code, under firmware/boot_fw, that supports the commands used by Control Center to download firmware via USB.  The boot firmware has its own, much simpler SDK API (no ThreadX, etc.).

For Control Center to recognize a device, it has to have one of the signatures in the drive .INF file (for USB download it looks like this is VID 0x04B4 / PID 0x00F3). So the issue becomes, how to get a device running 'real' firmware with your customized VID/PID to renumerate with the ones required by Control Center - and have the ability to replace itself with code downloaded over USB?

What you can do is redesign the .img that you program to flash so that it consists of two subprograms - your 'real' firmware, and a copy of the boot_fw. The SDKs have the ability to transfer control from one subprogram to the other (see CyFx3BootJumpToProgramEntry() in the boot SDK and CyU3PU***JumpBackToBooter() in the "normal" SDK). You'll want to modify linker scripts so that the subprograms start at fixed memory addresses (i.e. 0x40030000 for the 'real' firmware and 0x40070000 for the boot_fw).

You can modify the descriptors in the boot_fw project so that the PID is 0x00F3.  Compile the project with USB boot support enabled and SPI boot support disabled, then run arm-none-eabi-objcopy to convert the .elf into a binary file:
  arm-none-eabi-objcopy --input-target=elf32-littlearm --output-target=binary --strip-all ${ProjName} boot_fw.bin

In the 'real' firmware, you can then use a simple .S file to pull in the boot_fw as a blob:

.section .text.boot
.code 32

.global boot_fw
boot_fw:
.incbin "boot_fw.bin"

    The linker script for the 'real' firmware needs to place the blob at the same location it was compiled to (in the boot_fw project) and to make the boot_fw the start address of the (merged) program.

Now for the switching. The boot_fw can be augmented to have a variable that keeps track of whether this is the first boot following powerup, or not.

On first boot, the code should call CyFx3BootU***Start(CyTrue, ...) as that appears to be a requirement for switching from the 'real' firmware back to the boot_fw. (CyU3PU***JumpBackToBooter() throws an error if you don't do this). The boot_fw must load the USB descriptors of the 'real' firmware (since we tell CyFx3BootU***Start that we do not want to renumerate). This is a sticky part of the subprogram approach - the boot_fw subprogram needs access to the descriptors of the 'real' subprogram - so you need to build the subprograms accordingly. Once the descriptors are loaded the boot_fw calls CyFx3BootJumpToProgramEntry() with the address of the 'real' subprogram.

To reflash, you need the ability to signal the 'real' firmware that it is time to jump back to the boot_fw. How you do this is application-specific; one way would be on receipt of a vendor-specific SETUP request. When the 'real' firmware receives this signal from the host it shuts down all the FX3 peripherals and calls CyU3PU***JumpBackToBooter(boot_fw). 

Now the boot_fw has control again. It checks the "first boot" flag and sees that this is a reboot. This time it calls CyFx3BootU***Start(CyFalse) and loads the boot_fw USB descriptors (the ones that now identify it in a way compatible with Control Center). Then, it goes into USB boot mode, acting on commands from Control Center.

One modification you'll need to make to the USB boot code in the boot_fw is to ignore attempts to download into the boot_fw memory range (since that would destroy the firmware performing the download). Since Control Center seems to read back what was written as a verification, this means you can't download a merged .img to RAM when one (i.e. that was programmed to SPI flash) is already running. But "normal" images such as the CyBootProgrammer don't overlap boot_fw memory and *can* be downloaded. This is what allows you to rewrite the flash from Control Center.

What would be really nice is if Cypress eliminated the need for all of this by providing some way to jump back into the ROM bootloader in a way that only supports USB boot (i.e., as if the PMODE straps had been set for USB boot only).

Hope this helps,
Steve

感谢史提夫和lumpi，这真的很有帮助。



     以下为原文
  Thanks Steve and lumpi, this really helps.

需要装配，
请您详细解释我在固件和BooTyfw中必须做哪些更改才能获得合并固件？



     以下为原文
  AssemblyRequired,
    please can you explain with more details what changes I must do in my firmware and in boot_fw to get the merge firmware?

要重新编程SPI EEPROM，您可以简单地将MISO接地（引脚2和4的SPI EEPROM，我相信），然后连接FX3设备到主机。由于启动模式是“SPI回落到USB”和MISO被短路到地面，从EEPROM读取的数据将是无效的，FX3将回落到USB引导（默认引导加载程序）。然后你可以删除短（MISO到GND）并重新编程SPI EEPROM。



     以下为原文
          To re-program the SPI EEPROM you can simply short MISO to Ground (Pins 2 & 4 of SPI EEPROM I believe) before connecting FX3 device to host. Since the boot mode is 'SPI fallback to USB' and MISO is shorted to ground, the data read from EEPROM will not be valid and FX3 will fallback to USB boot(default Bootloader). Then you can remove the short (MISO to GND) and re-program the SPI EEPROM.   

尼克尔
我知道我可以改变PMODE，短MISO到GND，或者删除EEPROFF设备，并在程序包上重新编程。但是我需要在没有硬件改变的情况下重新编程。有API CUU3PUBBJUP ButtoBoter，但由于某种原因，它不起作用。因此，我试图了解为什么它不起作用，我只能用软件方法将设备返回到CyReSubBooToLoad。



     以下为原文
  NIKL,
    I know that I can change PMODE, short MISO to GND, or remove EEPROM from device and reprogramm it on programmator. But I need to reprogramm it without changes of hardware. There is API  CyU3PU***JumpBackToBooter but for some reason it not work. So I try to uderstand why it not work and how I can return my device to Cypress USB BootLoader only with software methods.

该API将控制转移到2级引导代码（也就是SDK提供的固件）。它不将控制转移到默认启动代码。



     以下为原文
   CyU3PU***JumpBackToBooter : that API transfers the control to 2-stage boot code ( that is again a firmware provided with the SDK). It does not transfer the control to the default boot code.

尼克尔
什么是2阶段引导代码？



     以下为原文
  NIKL,
    And what is 2-stage boot code?

请查看与FX3SDK固件示例一起提供的名为“BooToFFW”的固件项目。有一个自述文件以及固件的来源。



     以下为原文
   Please check out the firmware project named 'boot_fw' provided along with the FX3 SDK firmware examples. There is a readme file along with the source of the firmware.