[REF] How to checkpoint FPGA state?

rs,

I am only familiar with our ISE Impact JTAG cable, and the software we provide.

http://www.xilinx.com/products/design_tools/logic_design/design_entry/impact.htm
Thru the Impact software, one can program the device, read the system monitor to determine the temperature, and the voltages, and perform a verify.
The verify step places the readback contents of the device into a file called impact.bin if the proper environment variables are set by the user (in Windows XP, these are

set XIL_IMPACT_VIRTEX_DUMPBIN=1
set XIL_IMPACT_IGNORE_MASK_FILE=1

Parsing the readback file can be a bit arduous, as it is in binary format (I use a binary file editor that expresses the file in hex and binary), and we do not supply a map.  However, the .msk file (mask file) supplies information about where capture, and restore bits, and other dynamic content is located (so it may be ignored, as it changes).  Along with the ‘diff’ command (comapre two files, and express the differences, it isn’t too hard to find initial conditions (by changing them in your design), and other bit locations of interest.

Sorry I can not be of more help,

Austin Lesea
Principal Engineer
Xilinx San Jose

Workaround for fake FTDI chip on Windows

Recently, I bought some FTDI breakout boards as USB to serial converter. At first, everything works, but later after a driver update, nothing works any more. After a little bit search, it turns out the chips are actually fake chips (f..k)!

FTDI-FT232RLr real vs fake supereal

I don’t want to throw away the chips just as that (meanwhile, I’ve placed another order from another seller, let’s cross fingers), so I did a little bit search and then come across this post:

Update for a fake cable
However, the procedure is much simpler:
1. Download the driver from FTDI official website
2. Change the PID in the two INF files to the one you see in the Hardware Properties of the fake chip when connected to the PC
3. Turn off the “Driver Signature Validation” on Windows, restart, install the driver from device manager. And then it’s working as before.

(Sorry, FTDI, I didn’t expect they also make fake copies of the chip which is already at a low price.)

Arduino + NRF24L01 + STM32

Now the communication is more or less okay.

With ACK with Payload, two way communication can be done without change the role of PRX and PTX.

BUT: with send ACK with Payload length >= 18 bytes. the PRX won’t be able to receive anything. I’m not sure whether it’s a problem in Arduino+NRF24L01(PTX) or the STM32+NRF24L01(PRX).


 

31/03/2014: The problem turns out to be with the Arduino Mega board I’m using, when I use Serial.print to print the ACK package out with baudrate == 115200, arduino will halt after a while. I don’t know what’s the cause of this behavior. I decreased the baudrate to 57600 and reduce the data to be printed out, I can receive ACK package with payload length up to 32 bytes. However, I need to test what will happen when the distance increases. Anyway, next step is to design the two-way protocol.


 

And as for performance, I’m using interrupt on Arduino, but still I need to wait at least 8ms before sending another packet, so that I’m not quite sure this way is much better than the PRX-TX-switch-role solution.

I will try to implement the switch role solution and compare to see the exact results. I’m okay with the performance of the ACK-WITH-PAYLOAD now, I don’t want to spend extract time for implement approach (for now). (Maybe I will try with pcDuino).


 

01/04/2014: Arduino+nRF24L01 + STM32

The first past for Arduino to retrieve MPU6050 data from STM32 is done.

Change from C51 board back to Arduino

The C51 board helped me to quickly find the problem in the code for STM32. However, after some consideration, it’s not suitable for the task as remote controller agent connecting to PC (with USB2TTL converter). It has the basic controls over individual PINs and interrupt routines and everything, but effect to be put to make it work with UART and SPI interface together to have a proper communication protocol is just painful (for now), and the documentation and official support for this board/chip (it’s a custom-design board) is not so good. Most of all, the C51 board is difficult to be extended in future. While arduino is much better considering these disadvantages, pity though, the frequency is much lower than the C51 board (8/16 MHz comparing to 42MHz). But the coding should be simpler.

Trying:

Basic SPI library in Arduino + NRF24L01+ =>

1. Receive data from UART and send through NRF24L01+ (SPI)

2. Receive ACK with Payload, send to UART

3. Interrupt instead of Polling

NRF24L01+ two way communication

To achieve two way communication with NRF24L01+ modules, there are basically two ways:

1. Switch the role of PRX and PTX when it’s necessary, delay, idle time etc. need to be managed accordingly (may be tricky when complex and reliable communication protocol is to be implemented).
2. use ACK with PAYLOAD feature with Enhanced ShockBurst.
ACK_PAYLOAD.png
The drawback with this one is that since PRX won’t know what the ACK Payload should be before the MCU can download and handle the data from PTX, so that the Payload in ACK will be one package after the correct package. However, with proper protocol it could be usable.
Later I will investigate both the solutions and see which is easier to be implemented and which has the better performance regarding the communication speed.

NRF24L01+ with Dynamic Payload

The step for Dynamic Payload for nRF24L01+ module has finished. The communication is done with STM32 and a C51 board. The Dynamic Payload length varies from 1 to 32.
There are still some glitches in the code (could be the UART I’m using now for debugging).

Next step, ACK package with Payload (tried, but not working, could be problem in C51 board, however, the flow for sending ACK with payload is not clear at STM32 end neither).