Spartan® Family FPGAs

[megyesibalazs]

Hi all,

First of all, I would like to create a multiboot configuration for my project, so I have created a header, a golden image and a multiboot image. I use an SPI-flash in quad mode, and if I program it with this configuration then multiboot image will start properly.

In fact, my problem occurs when I intentionally overwrite some bytes in the generated .mcs file to provoke a CRC error. So, I have changed some bytes in the multiboot image, and I have expected that the golden image would boot up, because multiboot image had a wrong CRC. Unfortunately, golden did not start, and the EOS was not detected at all. Here is the FPGA status after programming:

'1': Reading bootsts register contents...
[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[2] RESERVED                                                               :         0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR                                  :         0
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR                                  :         0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                      :         0
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[8] RESERVED                                                               :         0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR                                  :         0
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR                                 :         0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                     :         0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
'1': Reading status register contents...
[0] CRC ERROR                                                              :         0
[1] IDCODE ERROR                                                           :         0
[2] DCM LOCK STATUS                                                        :         1
[3] GTS_CFG_B STATUS                                                       :         0
[4] GWE STATUS                                                             :         0
[5] GHIGH STATUS                                                           :         0
[6] DECRYPTION ERROR                                                       :         0
[7] DECRYPTOR ENABLE                                                       :         0
[8] HSWAPEN PIN                                                            :         1
[9] MODE PIN M[0]                                                          :         1
[10] MODE PIN M[1]                                                         :         0
[11] RESERVED                                                              :         0
[12] INIT_B PIN                                                            :         0
[13] DONE PIN                                                              :         0
[14] SUSPEND STATUS                                                        :         0
[15] FALLBACK STATUS                                                       :         1

It is clear from the status that a CRC error was not detected. Why?

Naturally, among BitGen options I have selected the "Check CRC" and "Reset on error" checkboxes in both the golden and the multiboot projects.

After that, I have tried out CRC checking with a single multiboot image without a header and a golden one. Once again, I have intentionally overwritten the .mcs file slightly and programmed the flash. As expected, the image could not boot up, and now in the FPGA status CRC error was active, but it seemed that the configuration logic did not try to boot up 3 times, the srike count remained zero. However, in my view it should retry 2 more times to boot up. Here is the status in this case:

[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[2] RESERVED                                                               :         0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR                                  :         0
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR                                  :         0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                      :         0
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[8] RESERVED                                                               :         0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR                                  :         0
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR                                 :         0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                     :         0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
'1': Reading status register contents...
[0] CRC ERROR                                                              :         1
[1] IDCODE ERROR                                                           :         0
[2] DCM LOCK STATUS                                                        :         0
[3] GTS_CFG_B STATUS                                                       :         0
[4] GWE STATUS                                                             :         0
[5] GHIGH STATUS                                                           :         0
[6] DECRYPTION ERROR                                                       :         0
[7] DECRYPTOR ENABLE                                                       :         0
[8] HSWAPEN PIN                                                            :         1
[9] MODE PIN M[0]                                                          :         1
[10] MODE PIN M[1]                                                         :         0
[11] RESERVED                                                              :         0
[12] INIT_B PIN                                                            :         0
[13] DONE PIN                                                              :         0
[14] SUSPEND STATUS                                                        :         0
[15] FALLBACK STATUS                                                       :         1

Could anyone explain these strange behaviours?

Best regards

[bhayes47]

Hi,

Not sure if this might be your problem, but be sure you have the "-g next_config_register_write:disabled" set when you generate the multiboot image.  If this isn't set, a present but corrupted multiboot image won't properly fallback to the golden image.

Also, there is an issue with the generation of multiboot images with SPI widths greater than 1 in some versions of the tools.  See this thread for details of both issues.

Bill

[megyesibalazs]

I don't use the -g "next_config_register_write:disabled" option, but I have checked the generated .bit file and I am sure that GENERALn registers are not written in the multiboot image.

But if I use a single bitstream with the multiboot image I have definitely an uncorrect behaviour. In the generated MCS file, I have searched for the CRC words and I have modified it. I have programmed with this modified file the SPI-PROM. Surprisingly, the FPGA could boot up! However it mustn't! Here are my settings for BitGen:

-bd CPX-Counter_app.elf
-w
-g DebugBitstream:No
-g Binary:no
-g CRC:Enable
-g Reset_on_err:Yes
-g ConfigRate:26
-g ProgPin:PullUp
-g TckPin:PullUp
-g TdiPin:PullUp
-g TdoPin:PullUp
-g TmsPin:PullUp
-g UnusedPin:PullDown
-g UserID:0xFFFFFFFF
-g ExtMasterCclk_en:No
-g SPI_buswidth:1
-g TIMER_CFG:0xFFFF
-g multipin_wakeup:No
-g StartUpClk:CClk
-g DONE_cycle:4
-g GTS_cycle:5
-g GWE_cycle:6
-g LCK_cycle:NoWait
-g Security:None
-g DonePipe:No
-g DriveDone:No
-g en_sw_gsr:No
-g drive_awake:No
-g sw_clk:Startupclk
-g sw_gwe_cycle:5
-g sw_gts_cycle:4

What's wrong with this? When I read back the device status I will get all zeros:

[0] VALID_0 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[1] FALLBACK_0 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[2] RESERVED                                                               :         0
[3] WTO_ERROR_0 - WATCHDOG TIME OUT ERROR                                  :         0
[4] ID_ERROR_0 - FPGA DEVICE IDCODE ERROR                                  :         0
[5] CRC_ERROR_0 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                      :         0
[6] VALID_1 - ERROR OR END OF STARTUP (EOS) DETECTED                       :         0
[7] FALLBACK_1 - FALLBACK RECONFIGURATION ATTEMPT DETECTED                 :         0
[8] RESERVED                                                               :         0
[9] WTO_ERROR_1 - WATCHDOG TIME OUT ERROR                                  :         0
[10] ID_ERROR_1 - FPGA DEVICE IDCODE ERROR                                 :         0
[11] CRC_ERROR_1 - CYCLIC REDUNDANCY CHECK (CRC) ERROR                     :         0
[12] STRIKE CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[13] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[14] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
[15] STRIKE_CNT - STRIKE COUNT FOR FALLBACK ATTEMPTS                       :         0
'1': Reading status register contents...
[0] CRC ERROR                                                              :         0
[1] IDCODE ERROR                                                           :         0
[2] DCM LOCK STATUS                                                        :         0
[3] GTS_CFG_B STATUS                                                       :         0
[4] GWE STATUS                                                             :         0
[5] GHIGH STATUS                                                           :         0
[6] DECRYPTION ERROR                                                       :         0
[7] DECRYPTOR ENABLE                                                       :         0
[8] HSWAPEN PIN                                                            :         0
[9] MODE PIN M[0]                                                          :         0
[10] MODE PIN M[1]                                                         :         0
[11] RESERVED                                                              :         0
[12] INIT_B PIN                                                            :         0
[13] DONE PIN                                                              :         0
[14] SUSPEND STATUS                                                        :         0
[15] FALLBACK STATUS                                                       :         0

In fact, I have tested this with XC6SLX25 device, and I use ISE Design Suite 14.1.

[megyesibalazs]

I have found out that if I use the -g "Reset_on_err:Yes" option then a bitstream with invalid CRC can boot up. If I set this option to No, then the behaviour is as expected: the FPGA could not boot up.

What can cause this strange behaviour? In fact, in my multiboot project I need the "Reset on error" feature, because in case of a CRC error I would like to fallback to the golden image.

[bhayes47]

From your description, I can't be sure of what exactly you have happening.  However, you say you have verified that the General registers are not written in the multiboot image even though you have not used the disable flag ("-g next_config_register_write:disabled" ) to cause those writes to be replaced with NOPs.  In my experience, that is not possible, you must use that flag in the multiboot image, or else the General register writes will be there, and the multiboot image, if it doesn't configure itself, will not successfully fallback to the golden.

From your last post, it sounds like what it is happening is that when you set "-g Reset_on_err:Yes", you are not configuring the multiboot image that has the bad CRC, but that in fact it is falling back to the golden, which is what you actually want.

I may be wrong, but it is my understanding that an image with a bad CRC will never configure, period, assuming that you have set "-g CRC" to enable that checking, which is the case in your status report.  So if you have corrupted the CRC, then the image that is loading is some other image.  Are you sure that you don't have the golden image still in the flash, even though you didn't reprogram it ? 

Bill

[megyesibalazs · Accepted solution]

Yes you are right, I have missed in the multiboot image the "-g next_config_register_write:disabled" option. Now GENERAL register writes are replaced by NOPs and everything works fine.

Thanks for your quick reply.