cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jreinauld
Adventurer
Adventurer
887 Views
Registered: ‎02-24-2017

Write to external peripheral fails

Jump to solution

Hi everyone,

My MicroBlaze system crashes or freezes when I try to access an external peripheral.

The AXI transactions itself seems to complete without issue, but the program does not continue after.

Here are the details:

 

I have a KC705 devkit with a MicroBlaze system that works well (I was able to make a lwIP Echo Server work).

Now, I have added an AXI master to my peripheral interconnect connected it to an AXI4 to AXI4Lite bridge which I connected to an external port called 'external_cores'.
In the address editor I mapped this external peripheral to a 2MB space.

Here is the system and associated address map:

mb_subsystem.png

MEM.png

At the top level, the 'external_cores' active-low asynchronous reset is resynchronized as an active-high synchronous reset.
The 'external_cores' AXI4Lite interface is connected to a bridge that translates AXI4Lite into a simple memory-mapped protocol.
Then the memory-mapped bus is connected to a 32 x 4 bytes memory.

top_level.png

In order to test, I wrote a simple C program that attempts to write a 0xAA byte at the first address of the 'external_cores' space.

SOFT (1).png

When I run it, it does not work at all. The program freezes when it executes the write instruction:

TERM.png

I put an ILA that monitors the 'external_cores' AXI4Lite interface, and (unless I am mistaken) it turns out the write transaction occurs properly.

ILA.png

I modified the C program and kept only the write instruction, and I tried to trace it step by step using the SDK System Debugger.

SOFT2 (1).png

I won't explain each line of the assembly code, the important thing is that the write transaction corresponds to the sbi instruction at address 0x80000654.

When I step the program, everything works fine and I can get step up to address 0x80000654.
At this moment:
- In the assembly pane, the arrow points on address 0x80000654.
- I still see the MicroBlaze call stack: _start1(), _crtinit() and main()
- A state command in the XSCT console tells me the MicroBlaze is in state Stopped (Step)
- I can refresh the memory pane without any problem
- I can refresh the register pane without any problem

SDK_BEFORE.png

Then I click the step button one more time to execute the write.
at that moment:
- In the assembly pane, there is no more arrow
- The MicroBlaze call stack has disappeared
- A state command in the XSCT console tells me the MicroBlaze is in state Running

SDK_AFTER1.png

- When I try to refresh the memory pane I get the following message: Memory read error at 0x80000638. Cannot stop MicroBlaze
- When I try to refresh the register I get the following message: Exception: Cannot stop MicroBlaze, and also for almost all registers the value displayed is N/A

SDK_AFTER2.png

Can anyone explain to me what is going on?

Thanks,

- Julien

0 Kudos
1 Solution

Accepted Solutions
jreinauld
Adventurer
Adventurer
616 Views
Registered: ‎02-24-2017

So tried to put small FIFOs on the AXI4Lite interface, just before the AXI4Lite-to-simple-memory-mapped bridge.

And now the it works fine:

SOLUCE.png

It seems the MicroBlaze waits for waddr and wdata are acknowledged with ready = 1 AND ONLY THEN waits for bvalid to be asserted.
In my case, since bvalid was sent BEFORE the MicroBlaze waited for the AXI transaction to complete forever.
Hence the MicroBlaze stick in Running state and the debugger not being able to regain control.

This looks like a bug of the MicroBlaze to me.
The 5 AXI4Lite channels should be independent.
And even admitting that bvalid assertion should come after waddr and wdata acknowledgement, then the MicroBlaze should not have acknowledged bvalid.

Can anyone provide me a answer on that topic?

Thanks,

- Julien

View solution in original post

0 Kudos
6 Replies
jreinauld
Adventurer
Adventurer
828 Views
Registered: ‎02-24-2017
I am a bit puzzled because I am quite sure the issue comes from the external access, and at the same time the AXI4Lite transaction I see with the ILA seems OK.
0 Kudos
jreinauld
Adventurer
Adventurer
826 Views
Registered: ‎02-24-2017
Also, I don't understand what happens once the sbi instruction has been executed, it seems the debugger cannot regain control of the MicroBlaze...
0 Kudos
jreinauld
Adventurer
Adventurer
815 Views
Registered: ‎02-24-2017
I even put breakpoints at addresses 0x0, 0x8, 0x10, 0x18, 0x20, etc. in case there would be an exception of some kind and then the processor would enter an infinite loop (which would explain why the debugger cannot regain control), but still the MicroBlaze remain in state 'Running' as soon as it executes the sbi instruction
0 Kudos
jreinauld
Adventurer
Adventurer
763 Views
Registered: ‎02-24-2017

Also, when I try the command 'stop' in the XSCT console, I get a 'Cannot stop MicroBlaze'

0 Kudos
jreinauld
Adventurer
Adventurer
738 Views
Registered: ‎02-24-2017

So i guess my question to Xilinx experts is:

what would make an otherwise functional MicroBlaze impossible to be stopped by the debugger?

0 Kudos
jreinauld
Adventurer
Adventurer
617 Views
Registered: ‎02-24-2017

So tried to put small FIFOs on the AXI4Lite interface, just before the AXI4Lite-to-simple-memory-mapped bridge.

And now the it works fine:

SOLUCE.png

It seems the MicroBlaze waits for waddr and wdata are acknowledged with ready = 1 AND ONLY THEN waits for bvalid to be asserted.
In my case, since bvalid was sent BEFORE the MicroBlaze waited for the AXI transaction to complete forever.
Hence the MicroBlaze stick in Running state and the debugger not being able to regain control.

This looks like a bug of the MicroBlaze to me.
The 5 AXI4Lite channels should be independent.
And even admitting that bvalid assertion should come after waddr and wdata acknowledgement, then the MicroBlaze should not have acknowledged bvalid.

Can anyone provide me a answer on that topic?

Thanks,

- Julien

View solution in original post

0 Kudos