Reverse engineering FNIRSI-5012H

[ataradov]

Yes, and?

Also, in my case SWD link is super unreliable when ADC is running. No idea why specifically, I have not investigated it. So debugging may be a bit complicated.

But there is really not much to debug there.

[thinkfat]

That was more directed to mg3100

[wasp09]

Ordered a hot air station on ebay.  It said shipped but seller did not response when I asked for a tracking number.   Perhaps the price was too good to be true.

Then I checked LCSC.  It says GD32F407VET6 is out of stock.  Would you know of a shop that ships GD32F407 to Canada?  I can only find STM32F407 on ebay or GD32F301 on aliexpress. 

BTW also cloned open-5012H tonight.   Both 4.8.4 and 7.3.1 arm-none-eabi  complained about NULL.   I am running debian stable. I had to add include <stddef.h> to common.h to get through the make.

Regards

[ataradov]

Then I checked LCSC.  It says GD32F407VET6 is out of stock.

GD32F407VGT6 is in stock. It is essentially the same part with more flash. But it is not important, it just won't be used. And it is actually cheaper at the moment.

Both 4.8.4 and 7.3.1 arm-none-eabi  complained about NULL.   I am running debian stable. I had to add include <stddef.h> to common.h to get through the make.

I'm using "gcc version 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907] (GNU Tools for Arm Embedded Processors 7-2018-q2-update)" and I see no issues or warnings of any sort.

[mg3100]

I'm using gcc-arm-none-eabi-9-2019-q4-major with buildtools gnu-mcu-eclipse-windows-build-tools-2.12-20190422-1053 under windows 10, also no problems.
It produces a different binary file of course but it still functions. Maybe this is the reason why I can't reproduce the white screen of death anymore?

Building the binary using eclipse needed some tweaking in the configuration before it compiled without errors.

I'm using a segger j-link to flash the device, the only thing I had to do was "route power to target" for the level convertors.
No need to use F2, it connects without problems.

[wasp09]

GD32F407VGT6 is in stock. It is essentially the same part with more flash. But it is not important, it just won't be used. And it is actually cheaper at the moment.

Ordered 3 x GD32F407VGT with 512K extra data flash.  Thanks.

[bson]

Given the need to reverse the bits on one of the channels, there is no way to get 100% reliable triggering at 250 MSPS. There is just no enough processing power.

Maybe a viable UX solution is to only allow triggering at full speed on the unreversed channel.  The other channel can be limited in triggering to what can be viably sustained.

But, it is impossible to trigger on 250MSa/s with a CPU that runs at 250MHz.  Even if it executes one instruction per cycle by placing the trigger code in SRAM, one cycle is not enough; it needs to least load a sample, advance a pointer [mod N] for a DMA ring buffer, compare the value, and conditionally continue with the next sample - and this is as simple as it possible can get; with perfect pipeline occupancy this is 5 or 6 cycles.  So it *can't* trigger properly, and can realistically only process every N samples.  Dave's suggestion of 10MHz sounds realistic, giving it 25 cycles per pass through the trigger detector.  This is undoubtedly why the triggering is so awfully poor and requires the signal to repeat until the trigger code eventually sees it.  It's possible this could be improved on if the CPU has an internal comparator that can be used to drive the detector, but even that is really sketchy stuff (not really instrument grade).

[ataradov]

Maybe a viable UX solution is to only allow triggering at full speed on the unreversed channel.  The other channel can be limited in triggering to what can be viably sustained.

That's how it works right now for 125 MSPS (2x62.5 MSPS).

Even if it executes one instruction per cycle by placing the trigger code in SRAM, one cycle is not enough; it needs to least load a sample, advance a pointer [mod N] for a DMA ring buffer

SIMD instructions process 4 samples at a time in one clock cycle. Otherwise even triggering at 62.5 MSPS would be impossible.

Here is the triggering code in all its assembly beauty https://github.com/ataradov/open-5012h/blob/master/trigger.c

With 250 MSPS the issue is that there is no way to get all the data into the device. The DMA just does not have the performance and misses samples.

[splin]

Here is the triggering code in all its assembly beauty https://github.com/ataradov/open-5012h/blob/master/trigger.c

You can do better by taking advantage of the Cortex saturation flag (Q flag). The following code takes a fraction more than 2 cycles to check 4 buffer values which should allow it to handle real time triggering at 250MSPS (2 x 8bit samples @ 125MSPS). It's a shame the DMA can't maintain that rate.

Presumably the samples from the two ADCs are interleaved in the buffer with alternate samples being bit reversed. Thus the trigger search will only check the two non-reversed buffer entries.

Code: [Select]


int trigger_find_rise_single(uint32_t buf, uint32_t count, uint32_t g_trigger_levels)
{
...
...
...

//Clear the saturation (Q) flag
    MRS r5, APSR
    BIC r5, r5, #(1<<27)
    MSR APSR_nzcvq, r5

   //Set triggers to (256 - trigger_level) (for rising edge) for the two non bit-reversed samples per 4 buffer samples,
   // zero for the two which are reversed.


TrigLoop:
    LDM        %[buf]!, { b0, b1, b2, b3, b4, b5, b6, b7 }
    UQADD8    t, %[triggers], b0 ;Sets saturation (Q) flag if saturation occurs,
    UQADD8    t, %[triggers], b1 ; otherwise leaves Q flag unchanged
    UQADD8    t, %[triggers], b2
    UQADD8    t, %[triggers], b3
    UQADD8    t, %[triggers], b4
    UQADD8    t, %[triggers], b5
    UQADD8    t, %[triggers], b6
    UQADD8    t, %[triggers], b7

    //Repeat as many times as desired to reduce the loop overhead:
    LDM        %[buf]!, { b0, b1, b2, b3, b4, b5, b6, b7 }
    UQADD8    t, %[triggers], b0
    UQADD8    t, %[triggers], b1
    UQADD8    t, %[triggers], b2
    UQADD8    t, %[triggers], b3
    UQADD8    t, %[triggers], b4
    UQADD8    t, %[triggers], b5
    UQADD8    t, %[triggers], b6
    UQADD8    t, %[triggers], b7

    //Check if saturation occured. Note that Q flag can't be tested directly.
    MRS r0, APSR
    TST r0, #(1<<27); Z is clear if Q flag was set
    BEQ TrigLoop    ;Saturation didn't happen so carry on looking for trigger

Triggered:
    //Saturation occurred - search through buffer looking for first entry that reached trigger level


[ataradov]

UQADD8 does not modify Q flag. At least according to the ARM DDI 0403D and a few other places.

[splin]

UQADD8 does not modify Q flag. At least according to the ARM DDI 0403D and a few other places.

It would be pretty silly if it didn't. See section 3.7 of the Cortex-M4 DevicesGeneric User Guide:

https://static.docs.arm.com/dui0553/a/DUI0553A_cortex_m4_dgug.pdf?_ga=2.5155316.61267785.1582642986-542401930.1582303288




Joseph Yiu's book 'The Definitive Guide to ARM Cortex-M3 andCortex-M4 Processors' also states that UQADD8 sets the Q flag.

Personally I find ARM's documentation confusing and poor. For example, there is no definition that I can see of when saturation occurs - is it when the value exceeds the maximum value that can be held by the target or is it when the value matches or exceeds the saturation value? It's actually the former as you'd probably expect but it isn't spelt out.

I raised an error report with ARM about misleading or missing flag information several years ago but got an arrogant 'brush off' response:

Hi xxxx,

Thanks for pointing out these.

> Errata from external InfoCenter for:
> Cortex-M series processors
> Cortex-M4 Devices Generic User Guide
>
> Home > The Cortex-M4 Instruction Set > General data processing instructions > SSUB16 and SSUB8
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/BABJJACB.html
>
> The description for the SSUB8 and SSUB16 instruction specifically states: "These instructions do not change the flags."
>
> But My understanding is that it sets the GE flags.
>
> This error applies to all the instructions which set the GE flags including SADD16, SSAX. USUB8, UASX etc.
>
> However all these instructions, except SUBB8/SUBB16, do show that GE is affected in the instruction set summary table.

The specific state is for "Condition flags", so no problem here.

> A separate issue is in the load/store instruction timing page:
>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0439b/CHDDIGAC.html
>
> Wrt LDM and STM it states: "So, a three element LDM takes 2+1+1 or 5 cycles when not stalled."
>
> So is it 4 or 5 cycles when not stalled? If it could be either then this should be reworded to clarify.

It should be 2+1+1 = 4 cycles. Our documentation team will fix this into our next release. Thanks.

Best regards,

Xuechun Gu
ARM Partner Enablement Group

For documentation, downloads and other useful resources see:
http://www.arm.com/support/

As far as I can see it hasn't been corrected.

[mikerj]

The armasm documentation states "The Q flag is not affected even if this operation saturates.".  This appears to be common for all the parallel saturating instructions.

[ataradov]

I will test it later today on the real hardware.

[thinkfat]

The same document states in table 3-1 that none of the saturating SIMD instructions modify the Q flag. See page 3-6, for example.

[splin]

The same document states in table 3-1 that none of the saturating SIMD instructions modify the Q flag. See page 3-6, for example.

That's because the ARM documentation is s**t.  The description on the QADD8 instruction on page 3-98 says:

Condition flags

These instructions do not affect the condition code flags.

If saturation occurs, these instructions set the Q flag to 1.

Given their business model it's pretty piss poor that they can't even document the instruction set properly. Take a look at the GE flags for example.  The instruction set table 3-1 shows some,  but not all the instructions that set the GE flags - USUB8, UADD8, SADD8 but not ssub8.

Much worse is the fact that not one of the actual instruction descriptions show the GE flags being set - the only mention is in the SEL instruction which uses the GE flags.

Personally I don't trust the ARM documentation much and prefer to use Joseph Yiu's book I mentioned earlied. I probably should have pursued my errata request with ARM (in 2017), but the email response gave me the impression that I would have been wasting my time.

[ataradov]

The following test code shows that Q flag nor any other flags are changed by uqadd8.

Code: [Select]

  uint32_t a = 0x00050000;
  uint32_t b = 0x00f00000;
  uint32_t apsr = 0xffffffff;
  uint32_t res = 0;

  asm volatile (R"asm(
    mrs    r5, APSR
    bic    r5, r5, #0xf8000000
    msr    APSR_nzcvq, r5

    uqadd8 %[res], %[a], %[b]

    mrs    %[apsr], APSR
    )asm"
    : [apsr] "+r" (apsr), [res] "+r" (res)
    : [a] "r" (a), [b] "r" (b)
    : "r5"
  );

APRS remain 0 for both a,b = 0x00050000,0x00f00000 and a,b = 0x00550000,0x00f00000. The result saturates as expected, but there is no detectable change in flags.

So ARM documentation appears to be correct in this case.

The test was performed on Cortex-M4F (SAM E54).

[splin]

The result saturates as expected, but there is no detectable change in flags.

So ARM documentation appears to be correct in this case.

The test was performed on Cortex-M4F (SAM E54).

That's unfortunate and the documentation does actually say it in the 'Cortex-M4 Devices Generic User Guide'  DUI0553.pdf

On page 3-98 describing the QADD instructions:

Operation

These instructions add or subtract two, four or eight values from the first and second operands
and then writes a signed saturated value in the destination register.

The QADD and QSUB instructions apply the specified add or subtract, and then saturate the result to
the signed range −2n–1 ≤ x ≤ 2n–1−1, where x is given by the number of bits applied in the
instruction, 32, 16 or 8.

If the returned result is different from the value to be saturated, it is called saturation. If
saturation occurs, the QADD and QSUB instructions set the Q flag to 1 in the APSR. Otherwise, it
leaves the Q flag unchanged. The 8-bit and 16-bit QADD and QSUB instructions always leave the Q
flag unchanged.

To clear the Q flag to 0, you must use the MSR instruction, see MSR on page 3-164.
To read the state of the Q flag, use the MRS instruction, see MRS on page 3-163.

Restrictions

Do not use SP and do not use PC.

Condition flags

These instructions do not affect the condition code flags.

If saturation occurs, these instructions set the Q flag to 1.

I saw the last line which is quite unequivocale but wrong (or at least highly misleading), and missed the note earlier that SIMD versions of the instructions, QADD8 and QADD16, don't change the Q flag. The 32 bit QADD which does support the Q flag is not a SIMD instruction.

The UQADD8 and UQADD16 SIMD instructions have the same behaviour presumably because the SIMD ALU doesn't have the necessary hardware.

It also seems that Joseph Yiu's book is simply wrong in this case:



The ARM instruction set documentation is still piss poor - just not quite as bad as I thought!

[ataradov]

One thing about ARM documentation is that those pseudo-code snippets they provide for each instruction and other functions are actually real code. That code is part of the formal verification process.

Obviously the code may still be edited more than necessary for the document, but in general it is correct despite of what the text says.

I think there is even the whole unmodified text of that pseudo-code published, but I can't remember where I saw it. There was some blog by an ARM engineer who was doing all sorts of fun analysis on that formal model.

This is the blog https://alastairreid.github.io/ A worthwhile read for anyone interested in low level details of ARM stuff.

And here is the link to the actual machine-readable architecture specifications https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools (appears to be only available for A-profile)

[Martinn]

Not so long wait... FNIRSI arrived, I changed the processor (as I described earlier, masking+hot air gun), soldered the new one (wave tip LTGW), cut off micro-USB cable and soldered to $2 ST-LINK clone. Programmed with ST-LINK utility and... it works!
Thanks Alex!

[Martinn]

Hmmm - shouldn't there be a grid visible? Somehow my screen looks different to the animated gif george posted earlier!

[ataradov]

The grid should be visible. But it has a very shitty LCD, so it is only visible under certain angles. The grid is actually drawn at the same time as trace, so it should be there on your unit too.

[Martinn]

You are right, it is there - under a certain angle I can faintly see something... but essentially invisible in regular use. Do you know if the LCD driver has a setting for adjusting it? Maybe gamma set?
Looking a the code
#define GRID_FG_COLOR          LCD_COLOR(200, 200, 200)
looks pretty bright to me, so there has to be something strange with the display.

[ataradov]

I don't know. On all my displays it looks pretty bright, you would definitely see it.

The are some display settings in lcd.c, which I just copied from some sample code, since I have no idea what any of them mean. But all displays should be the same, so I have no idea.

Changing the color may be your only real option.

[Martinn]

Just had a bit of a fight getting the compile to work. Had to install gcc-arm (link you provided), then gnu make, then modify makefile (gmkdir -> mkdir, remove -p option), setup all paths and as final bonus discover that the ST-link tool does not reload a binary if it has changed on disc.
Well, finally it works, I changed the grid to 255,255,255 and now it's perfectly visible. I'll maybe have to change some other colors too.

[wasp09]

Still waiting for GD32F407VGT6s and hot air gun from China.   The hot gun listed here won't ship to Canada.  Another seller took my order but did not really ship, no tracking number and no responses to my messages.  Wasted more than a month in that order.   A second order for a hot air gun was made on Aliexpress, tracking number is not valid yet.   GD32F407 last seen on March 1 in China.  It has not hit Canadian airspace yet.  Would LCSC has a dispute process if the shipment never shows up?

i do have a STM32F407VGT6 development board ordered on Aliexpress at the same time.  That passed Canadian Customs last week.  Expected delivery was March 17, but it has not arrived yet.  I could test the code on the STM32F407.  I would alter to code make use of the on board ADCs for a lower frequency scope with display onto my linux box or replaying onto my 5012H or 016 scope.

Do we know how many time/machine cycles we need to start up a scan on  GD32F407?  If we have some form of delay line we may start the scanning after an interrupt fires off.  How much delay we would need on such delay line?  In that case we can perform more detail time consuming processing after stocking up sufiicient number, say a few thousands, of scans since the VGs have an extra 512KB for data assuming it is fast enough for DMA...

BTW, the probe/front end sucks, at MHz range the 5012H shows more or less the same reading switching the probe from 1X to 10X.  That would be the next project after getting the scans displayed correctly.

Have fun.