irregular behavior in lib_spi?

[DemoniacMilk]

For quite some time ive been using lib_spi to provide data to an external device.
The data sent is read from a flash device with a page size of 256, so I send a maximum of 256 bytes per transfer (I do not begin/end a transmission every time. Instead, the current_index variable is set to 0 every time the init_transfer interface function is called and no transfer is in progress).

Everything was working fine until today. All the sudden im running into ET_ECALL (out of bounds) in spy_async.xc / case miso :> uint32_t data: / transfer8_async();

I cannot explain this behaviour, as everything worked well for multiple days.

For out of bounds accesses i thought i might print the current buffer index (current_index) that is used in the function and surprisingly the index never exceeded 255, everything worked well. Removing the print leads to an ET_ECALL again.

On changing the section

Code: Select all

                    current_index++;
                    if((current_index*sizeof(uint8_t)) == buffer_nbytes){
                        i[active_client].transfer_complete();
                    } else {
                        transfer8_async(sclk, mosi, miso,
                                ((uint8_t*movable)buffer_tx)[current_index]);
                    }

to

Code: Select all

                    current_index++;
                    if((current_index*sizeof(uint8_t)) >= buffer_nbytes){   // >= insadead ==
                        i[active_client].transfer_complete();
                    } else {
                        transfer8_async(sclk, mosi, miso,
                                ((uint8_t*movable)buffer_tx)[current_index]);
                    }

the error remained, although it should be impossible for current_index to be out of bounds at transfer8_async() due to being unsigned and replacing 'equal to' by 'greater than or equal to'.

I printed buffer_nbytes instead of current_index, and everything worked well (and values were as expected). on removing the print: ET_ECALL.

So a delay of 50 ticks was added before transfer8_async() and it works well again, I just have no absolutely no idea why this behaviour occured (I even replaced the relevant project files with older files and still had the problem).

[larry]

Are you at all able to reduce the failing program to a small example that runs in simulation? A simulator trace (xsim -t) would reveal a lot of information about the issue.

Have you done a clean build to see if this could possibly be a problem with compile dependencies?

[DemoniacMilk]

restarting the tools and doing a clean build seem to have fixed the issue, thanks for your reply