[Cryptech Tech] FMC Arbiter

Fredrik Thulin fredrik at thulin.net
Wed Sep 2 17:46:56 UTC 2015


On Tuesday, September 01, 2015 11:27:06 PM Павел Шатов wrote:
...
> Oops, Fredrik, you need to uncomment breaks in the main loop, I
> occasionally forgot to enable them.
> 
> Change
> if (test_ok < TEST_NUM_ROUNDS) /*break*/;
> to
> if (test_ok < TEST_NUM_ROUNDS) break;
> 
> If you've taken a look at the demo program, you've most probably seen,
> that the main loop repeatedly calls test_fpga_data_bus() and then
> test_fpga_address_bus(). Each of these test functions runs many rounds
> of testing and then returns number of successfully passed tests. Main
> loop checks, whether these numbers are smaller, than TEST_NUM_ROUNDS. If
> that is true, then there was an error, so main loop breaks and red light
> turns on.

Ah, thanks - that makes more sense. I didn't look at the code (it was late).

I have four dev boards here, and am troubleshooting some FMC issues. The worst 
issue seems to be that my Novena seems to have a defective (intermittently) 
pin somewhere.

Of my four boards, three fail more or less often with test_fpga_address_bus() 
diff of 0x80000 / 0b10000000000000000000. Which pin is that? It is the 20th 
bit from the right - does that mean it is FMC_A19?

For failures on the data test, I seem to get test_fpga_data_bus diff() values 
like 0x5997e383 (and not the same/bitwise similar value all the time) which 
doesn't make any sense at all to me. I need to experiment more there.

I imported your test program into my user/ft/stm32-dev-bridge repository (hope 
you don't mind) and made it work in my build environment, and made some minor 
changes to suit me better when debugging.

Primarily, I changed some interesting-to-look-at-in-the-debugger values to be 
volatile, so that my compiler wouldn't optimize/obscure them. I also changed 
the main loop to run one data and one addr test before checking for errors. 
This lets me break once I get to the fail-loop (when the red LED is turned 
on), and just look at what went wrong and when:

(gdb) continue
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x08003c70 in main () at src/main.c:118
118                     led_on(GPIO_PIN_LED_RED);
5: successful_runs = 0
4: data_test_ok = 0
3: addr_test_ok = 0
2: addr_diff = 536871424
1: data_diff = 2144577225
(gdb)

So this time, the board failed the very first data-test, and also the very 
first addr-test. The addr difference from expected result is '0x20000200' 
/'0b100000000000000000001000000000' but the data diff is '0x7fd3a6c9' / 
'0b1111111110100111010011011001001'. Hmm.

/Fredrik



More information about the Tech mailing list