[Cryptech Tech] FMC Arbiter
Pavel Shatov
meisterpaul1 at yandex.ru
Mon Sep 7 14:20:30 UTC 2015
On 02.09.2015 20:46, Fredrik Thulin wrote:
> 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.
That's bad news :( As far as I understand, there are two possible places
to look for this defect: expansion connector and FPGA. While pins of the
expansion connector can be inspected with a magnifying glass, solder
balls under FPGA can only be checked to some extent with an x-ray
machine. Can we try it on another Novena?
> 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?
That should be FMC_A17. STM32 has byte-addressable memory, while FMC
interface operates on 32-bit words, so the address is internally shifted
two bits to the right, before appearing on the address bus pins. This is
explained in section "37.4.1 NOR/PSRAM address mapping" of the reference
manual. After the demo program does address readback, it manually shifts
two bits to the left to compare properly.
What about the fourth board, btw?
> 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.
Can you give more details? Does this test fail on all four boards? How
often does it fail compared to address bus test? Did you notice any
specific patterns?
--
With best regards,
Pavel Shatov
More information about the Tech
mailing list