Debugging DIN

Duggle · March 20, 2013, 11:08am

I have a DINx4 PCB in a SRIO chain followed by 4 x Fairlightii PCBs.

The DINx4 with standard push buttons attached to the 1st Shift register weren’t working at all, then after some fiddling (changing the PCB and back again) were working as per the script o.k.

Today I power up again and it is back to as though no buttons are pressed when they are. I short Vs to D7 with screwdriver to eliminate the wiring to the buttons.

I have debug on. Should I see a notification in MIOS Studio when a button is toggled?

The Fairlightii PCB continue to work, so I know data is being shifted through the SRs of the DINx4 module.

I’m using the this bit of script with the buttons, which is the same if I isolate it and run just it.

The script has worked so I know it’s not that.

Any ideas on how to debug?

EVENT_BUTTON id=8 fwd_id=LED:33 type=Meta meta=SetBank button_mode=OnOnly range=1:1 radio_group=1 value=1
EVENT_BUTTON id=7 fwd_id=LED:34 type=Meta meta=SetBank button_mode=OnOnly range=2:2 radio_group=1
EVENT_BUTTON id=6 fwd_id=LED:35 type=Meta meta=SetBank button_mode=OnOnly range=3:3 radio_group=1
EVENT_BUTTON id=5 fwd_id=LED:36 type=Meta meta=SetBank button_mode=OnOnly range=4:4 radio_group=1

#####Patch Controller dump request######
EVENT_BUTTON id=4 fwd_id=LED:37 button_mode=OnOnly type=SysEx stream="0xf0 0x00 0x20 0x33 0x01 0x00 0x37 0x00 0x40 0xf7"

EVENT_BUTTON id=3 fwd_id=LED:38 type=NoteOn key=45 value=0
EVENT_BUTTON id=2 fwd_id=LED:39 type=NoteOn key=47 value=0
EVENT_BUTTON id=1 fwd_id=LED:40 type=NoteOn key=48 value=0

MIOS Studio terminal has this output upon loading the script, but nothing after this:

[5594.825] load buttons
[5594.843] [MBNG_FILE_C] Event Pool Number of Items: 8
[5594.843] [MBNG_FILE_C] Event Pool Allocation: 244 of 24576 bytes (0%)
[5594.843] MBNG_DIN_NotifyReceivedValue(8, 1)
[5594.843] MBNG_DOUT_NotifyReceivedValue(33, 1)
[5594.844] MBNG_DIN_NotifyReceivedValue(7, 0)
[5594.844] MBNG_DOUT_NotifyReceivedValue(34, 0)
[5594.844] MBNG_DIN_NotifyReceivedValue(6, 0)
[5594.844] MBNG_DOUT_NotifyReceivedValue(35, 0)
[5594.844] MBNG_DIN_NotifyReceivedValue(5, 0)
[5594.845] MBNG_DOUT_NotifyReceivedValue(36, 0)
[5594.845] MBNG_DIN_NotifyReceivedValue(4, 0)
[5594.845] MBNG_DOUT_NotifyReceivedValue(37, 0)
[5594.845] MBNG_DIN_NotifyReceivedValue(3, 0)
[5594.845] MBNG_DOUT_NotifyReceivedValue(38, 0)
[5594.846] MBNG_DIN_NotifyReceivedValue(2, 0)
[5594.846] MBNG_DOUT_NotifyReceivedValue(39, 0)
[5594.846] MBNG_DIN_NotifyReceivedValue(1, 0)
[5594.846] MBNG_DOUT_NotifyReceivedValue(40, 0)
[5594.846] Patch 'buttons' loaded from SD Card!

T.K · March 20, 2013, 10:24pm

You could also start with an empty .ngc file (or just the one which prints “hello world”), the debug mode will always print MBNG_DIN_NotifyReceivedValue() regardless of the EVENT configuration.

From the log it looks like the data input (resp. the data output of the DIN SR) is always 0

Best Regards, Thorsten.

/edit: the “empty file” should contain a RESET_HW command!

Duggle · March 20, 2013, 11:01pm

OK, I’ve main it really simple:

A new DIN board with 1 SR and pullups attached as the only device on J8/9.

RESET_HW

EVENT_BUTTON id=1 type=NoteOn key=36
EVENT_BUTTON id=2 type=NoteOn key=36
EVENT_BUTTON id=3 type=NoteOn key=36
EVENT_BUTTON id=4 type=NoteOn key=36
EVENT_BUTTON id=5 type=NoteOn key=36
EVENT_BUTTON id=6 type=NoteOn key=36
EVENT_BUTTON id=7 type=NoteOn key=36
EVENT_BUTTON id=8 type=NoteOn key=36

heres the log:

[3049.771] [FILE] Uploading /B.NGC with 314 bytes
[3049.827] [FILE] Upload of 314 bytes finished.
[3049.827] AUTOLOAD 'B'
[3049.827] [MBNG_FILE_C] Event Pool Number of Items: 8
[3049.836] [MBNG_FILE_C] Event Pool Allocation: 208 of 24576 bytes (0%)
[3049.836] MBNG_DIN_NotifyReceivedValue(1, 0)
[3049.836] MBNG_DIN_NotifyReceivedValue(2, 0)
[3049.836] MBNG_DIN_NotifyReceivedValue(3, 0)
[3049.836] MBNG_DIN_NotifyReceivedValue(4, 0)
[3049.836] MBNG_DIN_NotifyReceivedValue(5, 0)
[3049.838] MBNG_DIN_NotifyReceivedValue(6, 0)
[3049.838] MBNG_DIN_NotifyReceivedValue(7, 0)
[3049.838] MBNG_DIN_NotifyReceivedValue(8, 0)
[3049.838] Patch 'B' loaded from SD Card!

Duggle · March 21, 2013, 12:26am

Should the red LED on the Xpresso pcb ever go off? (I’m finding that mine goes off at some point even though the core is still communicating over USB with MIOS Studio o.k.)

I’ve loaded an empty.ngc file and there are no debug notifications.

I find that similar to the log in the last post, only notifications of EVENT declared elements are shown, and then only upon loading the ngc, allways showing 0, and after this, no notifications are received.

(I’ll note here, again, that when I connect the whole SRIO chain, the Fairlightii pcbs,as well as other DOUTs are working fine!)

I’m finding that when I type “help” MIOS Studio indicates that debug mode is switched on, which it isn’t, until I give the command.

Is this setting supposed to be “remembered”?

Duggle · March 21, 2013, 2:06am

Ok, this is getting interesting!

I’ve just compiled, and loaded tutorial/10_din and all the hardware works perfectly. All my DIN pcb’s are working (despite some abuse- J1 of DINx4 connected reversed, resulting in some hot chips!) This is verified with the complete SRIO chain with buttons connected and all.

There must be a bug in NG?

The crazy thing is that it wasn’t working, then after fiddling about it did work for some time, then at next power up the next day it wasn’t working again. I was sure it would be hw related.

So after the successful 10_din test, I just reflashed NG and the fault is back.

TK, I could send you my script but the fault is demonstrated by an empty script or simple one like above.

I have the latest bootloader and pre-compiled NG running in the core.

As always, thanks for your help!

T.K · March 21, 2013, 10:06am

I’m currently not at home and therefore can’t test your file.

I forgot to mention, that the “empty file” should contain a RESET_HW command.

Without this command, it could be that functions are active which shadow the DIN:

encoders
DIN matrices
KB matrices

With RESET_HW these configurations should be disabled.

Best Regards, Thorsten.

Duggle · March 21, 2013, 9:16pm

Yes, I discovered the significance of RESET_HW and have been using it like above.

Until you can look at this I’ll identify the simplest script that exhibits the problem, then maybe re-flash with an earlier release of NG. I can’t believe something so simple isn’t working (but I now know my hw is fine).

Duggle · March 21, 2013, 10:30pm

The simplest script is “empty.ngc” which consists of 1 command: RESET_HW

Of course we need enable debug information by typing “set debug on” at the MIOS Studio terminal to see the notifications.

I have various pre-compiled versions of MIDIbox NG in a folder:

V1.012 buttons o.k.

V1.019 buttons don’t work

V1.021 buttons don’t work

“Huston, we have a problem…”

T.K · March 21, 2013, 11:02pm

You are using a MBHP_CORE_STM32 module, most people are using a LPC17 module - this could make a difference.

It would be interesting if you notice changes if following switches are changed in the src/mios32_config.h file:

set MIOS32_SRIO_NUM_SR 16
set MIOS32_DONT_SERVICE_SRIO_SCAN 0
set MIOS32_SRIO_NUM_SR 16 and MIOS32_DONT_SERVICE_SRIO_SCAN 0

Best Regards, Thorsten.

Duggle · March 21, 2013, 11:22pm

No, this is a standard LPC17 core.

So the results I last posted hold for the following hardware setup consisting of only:

Standard LPC17 Core with latest bootloader

1 x DINx4 module with buttons connected to 1st SR

Based on this I’m suggesting a fundamental bug has been introduced sometime after V1.012

T.K · March 21, 2013, 11:48pm

Could you please try the different versions:

http://www.ucapps.de/mios32/backup/midibox_ng_v1_013.zip

http://www.ucapps.de/mios32/backup/midibox_ng_v1_014.zip

http://www.ucapps.de/mios32/backup/midibox_ng_v1_015.zip

http://www.ucapps.de/mios32/backup/midibox_ng_v1_016.zip

http://www.ucapps.de/mios32/backup/midibox_ng_v1_017.zip

http://www.ucapps.de/mios32/backup/midibox_ng_v1_018.zip

http://www.ucapps.de/mios32/backup/midibox_ng_v1_019.zip

Once we know the version which doesn’t work at your side, we could have a look into the SVN history to get an impression, what has been canged exactly…

Bes Regards, Thorsten.

Duggle · March 22, 2013, 12:33am

Thanks Thorsten, I’ll try them later today.

It will be very interesting to find out about this.

I say this because the buttons _did work _for brief period, with latest version, but not since.

Duggle · March 22, 2013, 7:15am

Unfortunately, I’ve had to use UART because older versions are not aware of the bootloader setting “single_usb”. Hence 4 USB devices appear and those old driver problems make it unusable.

The first observation is that under these circumstances (UART MIDI) debug feedback is printed only on loading an ngc not when events are generated?

The buttons work in V1.017 (and earlier) but do not work with V1.018 (and later)

I tested with all the versions you sent.

T.K · March 22, 2013, 8:15am

Debug messages are mostly sent to USB1, because UART is (much) to slow!

With v1.018 the keyboard driver has been introduced.

Type “kb 1” and “kb 2”

are the din_sr1 and din_sr2 values set to 0?

If not, these functions would shadow the “normal” DIN function.

Actually EVENT_HW should clear these SR definitions, it’s just an assumption.

Best Regards, Thorsten.

Duggle · March 22, 2013, 10:19pm

Yes, both “kb1” and “kb 2” yield din_sr1=0, din_sr2=0.

Hang on! I just realised V1.017 is loaded.

Flashing V1.018 now…

Same, both zero.

It might appear keyboard was added before V1.018?

T.K · March 22, 2013, 10:59pm

Are you saying that DINs are not working at your side with V1.017 as well?
There was no “critical” change between v1.017 and v1.018 which could cause this.
Yes, support for keyboards was introduced with v1.018, and this was also the version where I increased the SRIO scan frequency, etc…

Therefore it would be interesting, if this is a systematic bug which could “somehow” be reproduced with earlier versions.

And of course it would be interesting, if any other user noticed a similar problems with DINs?

I check the functionality of cfg/test/*.ngc files regularly with different hardwares, and haven’t noticed such an issue yet.

Best Regards, Thorsten.

Duggle · March 22, 2013, 11:53pm

Are you saying that DINs are not working at your side with V1.017 as well?

No, V1.017 is the latest that works.

V1.018 is the earliest to have this problem.

Why does V1.017 respond to “kb” query if keyboard support was added after this?

Duggle · March 23, 2013, 2:00am

I have wondered why there are no other reports of this.

To try to eliminate variables I am now using a new “virgin” Xpresso with it, in case some wrong value somehow got stored on eeprom or flash, that corrupts it’s behaviour somehow. Same result.

I should try an STM32 core next…

[edit]

O.K, I’ve just tested and it’s the same situation with the STM32:

Hardware: Core<->DINx4

Script: Just like in post#3

Result: V1.017 works,

V1.018 and later *do not work*

I’ll now have to leave it to others to reproduce the “bug”?

T.K · March 23, 2013, 12:00pm

What happens if you put the commands into the DEFAULT.NGC file?

Before testing this, create a backup of the current DEFAULT.NGC - the “history” could be important to know for the case that this solves the issue.

Best Regards, Thorsten.

Duggle · March 23, 2013, 5:59pm

The same results have been found whether loaded from DEFAULT.NGC or manually loaded from another file after startup.