Debugging DIN

[Duggle]

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!

 

 

[TK.]

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]

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]

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]

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!

[TK.]

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]

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]

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..." :rofl:

[TK.]

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:

 

1) set MIOS32_SRIO_NUM_SR 16

2) set MIOS32_DONT_SERVICE_SRIO_SCAN 0

3) set MIOS32_SRIO_NUM_SR 16 and MIOS32_DONT_SERVICE_SRIO_SCAN 0

 

Best Regards, Thorsten.

[Duggle]

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

[TK.]

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]

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]

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.

[TK.]

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]

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? 

 

[TK.]

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]

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]

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"?

Edited March 23, 2013 by Duggle

[TK.]

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]

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

[Duggle]

Working now!!!!

I am yet to investigate, but I put in a different sdcard, the core then generated a new DEFAULT.NGC, etc, and the default set up is reading the DIN o.k with all versions! :rolleyes: 
I will first of all copy all the files from the "faulty" sdcard to the new card, then see if the problem comes back, but I'll also zip the files for later inspection.

 

I guess the sdcard and it's contents (other than the *.ncg) was something I have been overlooking.

[Duggle]

Well it seems the problem lies in my projects default.ngc.

 

It only manifests the problem (not reading the first DINx4 SRs) if my project (sys.ngc renamed to default.ngc) is in the sdcard slot during power up. If it is, then loading a simple button reader script like in post #3 (buttons.ngc) will have the problem. It seems like only a power cycle will restore proper functionality (with another script such as buttons.ngc renamed to default.ngc). When this is done I can manually load sys.ngc and the DIN works o.k (there are still "LCD labels not updating" problems which are probably unrelated).

 

I stress the importance of "power cycle" in reproducing this fault.  When trying different scripts I have been tending to load manually, or type "reset" in MIOS Studio. 

 

TK, I will email the sys.ngc to you, as it is rather large, then when you can, see if you can reproduce.

Basically, if sys.ngc is default.ngc on power up, then the DIN problem persists until you power up with a different default.ngc

 

Note as before, this problem does not manifest on V1.017 and earlier.

 

OMG this has been very confusing! :wacko:

[TK.]

Found it! :smile:
 
The @(1:: ) directives in your .NGL file caused the issue.
This is a syntax error - actually you wanted to write @(1:1:1)
 
In v1.018 I enhanced the LCD label parser to cover more cases (reported by users) - and I overlooked this possible syntax error case.
With the effect, that @(1:: ) leads to an endless loop. The thread will never continue, therefore some functions (like DIN handler) won't be called anymore.
 
The fix is already available in the repository (the wrong directive "@(1::)" will now be print on screen - this complies to the way how printf() would handle an erroneous string)
 
Best Regards, Thorsten.

/edit: I'm writing @(1:: ) with space to avoid that the editor will replace : ) by a smilie :smile:

[Duggle]

yay! :happy:

 

More good news: it fixed the "LCD Labels value not changing" problem.

 

Thanks TK!