Jump to content

TK.

Administrators
  • Posts

    15,198
  • Joined

Posts posted by TK.

  1. Well done and nicely documented! :)

    The assembly code remembers me on the cycle accurate hacks that I did for MBHP_TV years ago - it's a nice experience to work on this level, as long as users don't start with enhancement requests ;-)

    But it seems that your solution is simple & powerful enough to satisfy requests at host level :)

    Best Regards, Thorsten.

  2. Testing the BLM the last couple of weeks I was getting intermittent behaviour. Notably the SEQ was having trouble communicating at power on and the miniCore would reset if too many blue LEDs were lit.

    While reading your posting an idea came into my mind: the PIC device configuration (which comes with the MIOS bootloader) is preconfigured with a brown-out reset detection at 4.5V, which means if the supply voltage falls below this limit, the PIC will be reset, although it also works at lower ranges.

    I selected this high BORV setting to ensure, that for example an ongoing IIC EEPROM programming operation will be interrupted (by resetting the PIC) before the external device is outside the valid voltage range during power-off - this could lead to data corruption.

    But the BLM16x16+X doesn't access external EEPROMs, so actually the BORV could be lowered to 2.89V or even 2.14V

    Unfortunately this can only be done with a PIC programmer.

    Best Regards, Thorsten.

     

  3. Does it make a difference if you replace the 8 100 ohm resistors by 220 ohm?

    100 Ohm has been selected in the original circuit since the LEDs are driven from 3.3V pins - but in your case they are driven from 5V pins which could lead to these ghosting effects.

    Best Regards, Thorsten.

     

  4. No, it won't help.

    The problem is, that the TPD has many DOUT shift registers, but only a single DIN shift register (as far as I remember). This results into an unbalanced serial output which leads to trouble when another module with DIN/DOUT registers (such as the BLM16x4) is connected.

    So - this kind of module will only work at the end of a serial chain, or with some buffering (and some luck) - it's a complex topic, I can't give you a fool-proven solution without further analysis (and I won't have the time for this anyhow... ;-)

    Best Regards, Thorsten.

  5. Meanwhile I also think that something is wrong with the cables, resp. the sockets (but this is hard to determine based on the snapshots).

    The notch of the J8/9 socket on the core module should show to the outer border, the same for the DIO module.

    Here a picture:

    mbhp_dio_matrix_10.jpg

    @Christian: can you confirm that the socket orientation of your board is the same like for the original MBHP_CORE_STM32F4 module?

    Best Regards, Thorsten.

  6. No special setup is required on the MIDI router.

    I'm no keyboard expert and therefore can't give you reliable information how to connect this particular hardware.

    But from the firmware side I think the most simple tests are the following:

    - turn off scan optimization (as mentioned above)

    - input test:
    connect a short cable from Vs (ground) to I0 -> up to 8 Note On messages should be sent.
    Note Off messages will be sent when the cable is removed.

    Repeat this test for the remaining inputs (J3:I0..I7 and J4:I0..I7)

    With this test, no proper break/make scheme is applied, and in worst case inputs stay at break and won't sent a note anymore - so, reset the core before repeating the next tests.


    - output test:
    instead of connecting I0 to ground, just connect it to O7/O6 via diodes (O7=make, O6=break; break has to be activated first; make sends the note).
    Only a single note on/off message should be sent.
    This can be repeated for the remaining output pairs.

    Best Regards, Thorsten.

  7. Could you please check with the "testaoutpin" command if the control signals also go to the DIN/SCLK/FS pin of the TLV5630? (pin 2/3/4) - if this is the case, the problem must be on the AOUT_NG board. Check all supply pins (GND and VDD pins), something seems to be wrong there.

    If still no luck, we can't exclude that the chip is defective.

    Best Regards, Thorsten.

     

  8. At a first glance I don't see a configuration error.

    However, I think that this combination can lead to unstable SRIO transfers because of the high number of SRIOs and different chain lengths of the DIN/DOUT SRs. This would also explain, why the BLM acts strange.

    A prober solution to overcome this problem is MBHP_LINE_DRIVER: http://www.ucapps.de/mbhp_line_driver.html

    I don't know how exactly your hardware looks like, but if the TPD is close to the wilba frontpanel, then it's sufficient to connect the transmitter/receiver between TPD and BLM4x16

    Best Regards, Thorsten.

  9. Does the voltage change at the TLV5630 outputs (pin 12, 13, 14, 15, 6, 7, 8, 9)?

    See the schematic to find the outputs: http://www.midibox.org/dokuwiki/lib/exe/fetch.php?media=seppoman:mbhp_aout_ng_r1_schematic.pdf

    The REF output might be interesting as well, it should output 2V once the TLB5630 has been correctly configured.

    You can re-configure the device in the MBSEQ CV Configuration page during runtime (w/o power-cycling the core) by selecting a different interface, and then AOUT_NG again.

    Last but not least: I just noticed that there is an integrated AOUT troubleshooting app in the MBSEQ firmware, which might help as well!
    Enter "testaoutpin" in MIOS Terminal to get the appr. help page

    Best Regards, Thorsten.

  10. Hi Nico,

    on the SC line you should see a burst of 128 clock cycles each mS
    The RC line will send a short pulse before and after the SCLK pulse
    The SO line will output the patterns during the SC burst.
    The SI line should send a pattern during the SC burst. It's all-1 if no button is pressed.

    Testing with a scope is rel. simple: just ensure that the SC and RC signal is visible on all 74HC595/165 CLK/LD inputs.
    And check that the serial inputs and outputs transfer the pattern.

    If one of the chips doesn't output the pattern, it's either because it doesn't get a pattern at the input, or because a short/power problem at this IC (in worst case the IC is defective, but this would be unusual).

    Schmitt Trigger: immediately forwards the input data. If you don't see any toggles at the outputs, it's related to a short/power issue.

    Best Regards, Thorsten.

×
×
  • Create New...