05-23-2011 05:12 AM
Dear Mr. Chapman,
my application use Pico Blaze processor in Spartant3A FPGA.
String received from uart is storage in Scratch Pad Memory Locations:
CONSTANT string_start, 10
CONSTANT addr_rq, 11
CONSTANT end_string, 18
after data processing the string is sent back to master with reply_string procedure:
reply_string: LOAD s2,string_start
next: FETCH UART_data,(s2)
COMPARE s2,19 ;19 = end_string+1
but the FETCH istruction faliure and the replied message is corrupted.
What is the problem?
This solution works properly with Spartan3E.
05-23-2011 06:16 AM
I’m happy to give general advice to PicoBlaze users but I really can’t provide a remote debugging service for specific designs.
If you are doing exactly as you describe then I can see no reason why it would not work. Just moving from Spartan-3E to Spartan-3A is definitely not the reason because people have been implementing PicoBlaze designs on both devices for many years so I would be more suspicious about things like the board you are using, the clock frequency, baud rate setting etc.
As with any debugging it always helps if you break the problem down into stages with known boundaries. I suggest you manually load your ‘UART_data’ register with a series of characters forming a known message (e.g. "PicoBlaze") so you can see if basic communication works first. May be you have an interrupt that is corrupting the communication process or something? Then try loading that same message into the scratch pad locations and using your ‘reply_string’ routine. If that works then your program must be writing corrupted data into scratch pad for some reason.
Principal Engineer, Xilinx UK