RESOLVED: v4 FPGA bug?? Not handling non-aligned HUB execution
mindrobots
Posts: 6,506
***ISSUE HAS BEEN RESOLVED WITH FIX IN V4 FPGA IMAGE ***
Chip,
This testing triggered from this post in the "FPGA Files" thread.
78RPM had a hub exec routine that started at $43d2 that was failing. I tried it with my smaller hub exec loop back test and found that it did not work on v4 with unaligned instructions but worked on v3 with unaligned instructions. To fix v4, we were able to put an ALIGNL before the instruction but in 78rpm's and probably OzPropDev's programs, that is impractical.
It looks like we lost unaligned hub exec in v4.
The program below works on v3 without the ALIGNL but only work on V4 with the ALIGNL.
Chip,
This testing triggered from this post in the "FPGA Files" thread.
78RPM had a hub exec routine that started at $43d2 that was failing. I tried it with my smaller hub exec loop back test and found that it did not work on v4 with unaligned instructions but worked on v3 with unaligned instructions. To fix v4, we were able to put an ALIGNL before the instruction but in 78rpm's and probably OzPropDev's programs, that is impractical.
It looks like we lost unaligned hub exec in v4.
The program below works on v3 without the ALIGNL but only work on V4 with the ALIGNL.
con SYS_CLK = 50_000_000 BAUD_RATE = 115_200 RX_PIN = 63 TX_PIN = 62 dat orgh 0 org 0 jmp #@cog_entry ' these need to stay here (under org 0) so they are in COGRAM and get initialized bit_time long SYS_CLK / BAUD_RATE tx_char res 1 timer res 1 rx_char res 1 ' plenty of room to play in High HUBRAM (COG0 in HUBEXEC at this point) orgh $4300 cog_entry setb outb, #TX_PIN setb dirb, #TX_PIN '******************************************************* '********* TEST CODE - PUT YOUR CODE HERE ************** ' ***** try some input/output loopback call #@rcv_char mov tx_char, rx_char call #@send_char jmp #@loopback '********* TEST CODE - REPLACE WITH YOUR CODE *********** '******************************************************** '******************************************************************************* ' Get one character from the input port. ' Input none ' Changes parm, temp, temp1, temp2 ' Output parm '******************************************************************************* orgh $43d2 ' this works with v3 FPGA image ' ALIGNL ' needed with _v4 FPGA image rcv_char setedg #%0_10_000000 | RX_PIN 'select negative edge on p63 polledg 'clear edge detector waitedg 'wait for start bit waitx bit_time 'wait for middle of 1st data bit rep @.rep,#8 'ready for 8 bits testb inb,#RX_PIN wc 'sample rx rcr rx_char,#1 'rotate bit into byte waitx bit_time 'wait for middle of nth data bit .rep shr rx_char,#32-8 'justify received byte ret '******************************************************************************* ' Output a single character to the tx_pin. ' executes in COG mode ' Input: txchar - character to be sent ' Changes parm, temp1, temp2 ' Output none '******************************************************************************* send_char setb tx_char,#8 shl tx_char,#1 getct timer rep @.txrep,#10 testb tx_char,#0 wz setbnz outb,#TX_PIN addct1 timer,bit_time waitct1 shr tx_char,#1 .txrep ret
Comments
*I would think I would go to the bad instruction (mis-aligned) in the isr and the program would just go off in the weeds never finding a properly aligned iret.
long 0[16]
The latest PNut.exe only downloads what data was emitted, as opposed to the whole hub image.
Maybe there is a problem with the new WFBYTE flushing properly.
By adding extra data, it will ensure that the data of importance is full downloaded.
If that 'long 0[16]' works, see if 'byte 0' works, as well.
a JMP to a non-long aligned address works, a CALL/INT to a non-long aligned address does not work *BUT* somehow it figures out alignment with the next instruction fetch because when I insert a NOP as the first instruction of isr, it DOES work.
If I make the 'hubexec jmp #back2cog' line at offset 3, nothing works.
I must find out what I broke. This most likely has something to do with the modifications I just made to the FIFO code to get partial data to write ASAP. I'm looking into it now.
Sorry about this. Hopefully, we'll get this squirt away in the next hour.
My program does not use RDFAST unless:
loc ptrb, #cog_start setq #(cog_end-cog_start) ' thank you Searith rdlong 0, PTRBinvokes RDFAST action?This is easier!
Excellent!
In future, may I ask you to issue Bug Request forms to the testers to give us a sporting chance?
How about Bug Reports??
Of course, I should really follow my own advice and raise Requests when I encounter coding problems, rather than blame the hardware. However, as everyone here knows, my code is laughable pointless abysmal feature rich and perfect! (BwaHaHaHaHaHaHA!)
Every branch into hub invokes a hidden RDFAST, though.
Thanks, Chip!!
If anyone is using a DE2-115 or a DE0-Nano, they need the newer files.