Jump to content

M-atthias

Members
  • Content Count

    69
  • Joined

  • Last visited

  • Days Won

    6

Reputation Activity

  1. Like
    M-atthias got a reaction from solipso in LDMIA & Interrupts Silicon Bug   
    Dear TI geeks,
     
    Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble.
     
    Matthias
     
     
      LDMIA and some other opcodes with a register list can be interrupted and
      continued afterwards in M3 and M4 cores.

      Unfortunately, there seems to be a silicon bug in some chips / core revisions
      that causes an interrupted LDMIA opcode to fail.

      The error has already been observed in LM4F120, TM4C1294, STM32F407
      when using the multitasking example. M0 chips and EFM32GG990 are fine.

      It could affect other M4 chips and maybe M3, too.

      So if you get mysterious crashes when using Interrupts on M3/M4,
      try disabling preemption capabilities with this workaround:

      1 $E000E008 !

      Drawback is that this increases interrupt latency.

      Manual snipplets:

      B1.5.10 Exceptions in LDM and STM operations

           In order to allow implementations to have the best possible interrupt response, an interrupt can be taken
           during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or
           STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on
           page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is
           IMPLEMENTATION DEFINED.
           The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM
           or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not
           supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM,
           STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base
           register writeback update) during execution.

      M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html
      M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html
     
      Address     Name   Type  Required privilege  Reset value  Description
      0xE000E008  ACTLR  RW    Privileged          0x00000000   Auxiliary Control Register

      Auxiliary Control Register

      [0]    DISMCYCINT     Disables interruption of multi-cycle instructions.
             This increases the interrupt latency of the processor because load/store and
             multiply/divide operations complete before interrupt stacking occurs.

      M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html
      Does not have this bit.
     
  2. Like
    M-atthias got a reaction from bluehash in LDMIA & Interrupts Silicon Bug   
    Dear TI geeks,
     
    Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble.
     
    Matthias
     
     
      LDMIA and some other opcodes with a register list can be interrupted and
      continued afterwards in M3 and M4 cores.

      Unfortunately, there seems to be a silicon bug in some chips / core revisions
      that causes an interrupted LDMIA opcode to fail.

      The error has already been observed in LM4F120, TM4C1294, STM32F407
      when using the multitasking example. M0 chips and EFM32GG990 are fine.

      It could affect other M4 chips and maybe M3, too.

      So if you get mysterious crashes when using Interrupts on M3/M4,
      try disabling preemption capabilities with this workaround:

      1 $E000E008 !

      Drawback is that this increases interrupt latency.

      Manual snipplets:

      B1.5.10 Exceptions in LDM and STM operations

           In order to allow implementations to have the best possible interrupt response, an interrupt can be taken
           during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or
           STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on
           page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is
           IMPLEMENTATION DEFINED.
           The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM
           or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not
           supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM,
           STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base
           register writeback update) during execution.

      M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html
      M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html
     
      Address     Name   Type  Required privilege  Reset value  Description
      0xE000E008  ACTLR  RW    Privileged          0x00000000   Auxiliary Control Register

      Auxiliary Control Register

      [0]    DISMCYCINT     Disables interruption of multi-cycle instructions.
             This increases the interrupt latency of the processor because load/store and
             multiply/divide operations complete before interrupt stacking occurs.

      M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html
      Does not have this bit.
     
  3. Like
    M-atthias got a reaction from dubnet in LDMIA & Interrupts Silicon Bug   
    Dear TI geeks,
     
    Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble.
     
    Matthias
     
     
      LDMIA and some other opcodes with a register list can be interrupted and
      continued afterwards in M3 and M4 cores.

      Unfortunately, there seems to be a silicon bug in some chips / core revisions
      that causes an interrupted LDMIA opcode to fail.

      The error has already been observed in LM4F120, TM4C1294, STM32F407
      when using the multitasking example. M0 chips and EFM32GG990 are fine.

      It could affect other M4 chips and maybe M3, too.

      So if you get mysterious crashes when using Interrupts on M3/M4,
      try disabling preemption capabilities with this workaround:

      1 $E000E008 !

      Drawback is that this increases interrupt latency.

      Manual snipplets:

      B1.5.10 Exceptions in LDM and STM operations

           In order to allow implementations to have the best possible interrupt response, an interrupt can be taken
           during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or
           STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on
           page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is
           IMPLEMENTATION DEFINED.
           The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM
           or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not
           supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM,
           STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base
           register writeback update) during execution.

      M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html
      M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html
     
      Address     Name   Type  Required privilege  Reset value  Description
      0xE000E008  ACTLR  RW    Privileged          0x00000000   Auxiliary Control Register

      Auxiliary Control Register

      [0]    DISMCYCINT     Disables interruption of multi-cycle instructions.
             This increases the interrupt latency of the processor because load/store and
             multiply/divide operations complete before interrupt stacking occurs.

      M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html
      Does not have this bit.
     
  4. Like
    M-atthias got a reaction from Fmilburn in LDMIA & Interrupts Silicon Bug   
    Dear TI geeks,
     
    Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble.
     
    Matthias
     
     
      LDMIA and some other opcodes with a register list can be interrupted and
      continued afterwards in M3 and M4 cores.

      Unfortunately, there seems to be a silicon bug in some chips / core revisions
      that causes an interrupted LDMIA opcode to fail.

      The error has already been observed in LM4F120, TM4C1294, STM32F407
      when using the multitasking example. M0 chips and EFM32GG990 are fine.

      It could affect other M4 chips and maybe M3, too.

      So if you get mysterious crashes when using Interrupts on M3/M4,
      try disabling preemption capabilities with this workaround:

      1 $E000E008 !

      Drawback is that this increases interrupt latency.

      Manual snipplets:

      B1.5.10 Exceptions in LDM and STM operations

           In order to allow implementations to have the best possible interrupt response, an interrupt can be taken
           during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or
           STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on
           page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is
           IMPLEMENTATION DEFINED.
           The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM
           or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not
           supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM,
           STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base
           register writeback update) during execution.

      M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html
      M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html
     
      Address     Name   Type  Required privilege  Reset value  Description
      0xE000E008  ACTLR  RW    Privileged          0x00000000   Auxiliary Control Register

      Auxiliary Control Register

      [0]    DISMCYCINT     Disables interruption of multi-cycle instructions.
             This increases the interrupt latency of the processor because load/store and
             multiply/divide operations complete before interrupt stacking occurs.

      M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html
      Does not have this bit.
     
  5. Like
    M-atthias got a reaction from spirilis in LDMIA & Interrupts Silicon Bug   
    Dear TI geeks,
     
    Ulrich Hoffman found a bug while using multitasking in Mecrisp-Stellaris on TM4C1294, which, after a long search, could be tracked down and turned out to be a silicon bug. I wish to share this with you, just in case you run into similiar trouble.
     
    Matthias
     
     
      LDMIA and some other opcodes with a register list can be interrupted and
      continued afterwards in M3 and M4 cores.

      Unfortunately, there seems to be a silicon bug in some chips / core revisions
      that causes an interrupted LDMIA opcode to fail.

      The error has already been observed in LM4F120, TM4C1294, STM32F407
      when using the multitasking example. M0 chips and EFM32GG990 are fine.

      It could affect other M4 chips and maybe M3, too.

      So if you get mysterious crashes when using Interrupts on M3/M4,
      try disabling preemption capabilities with this workaround:

      1 $E000E008 !

      Drawback is that this increases interrupt latency.

      Manual snipplets:

      B1.5.10 Exceptions in LDM and STM operations

           In order to allow implementations to have the best possible interrupt response, an interrupt can be taken
           during an LDM or STM and continued after the return from the interrupt. The continuation state of the LDM or
           STM is held in the ICI bits in the EPSR (see The special-purpose program status registers (xPSR) on
           page B1-8). It is IMPLEMENTATION DEFINED when interrupts are recognized, so the use of the ICI bits is
           IMPLEMENTATION DEFINED.
           The ARMv7-M architecture supports continuation of, or restarting from the beginning, an abandoned LDM
           or STM instruction as outlined below. Where an LDM or STM is abandoned and restarted (ICI bits are not
           supported), the instructions should not be used with volatile memory. To support instruction replay, the LDM,
           STM, PUSH and POP instructions are required to restore/maintain the base register when a fault occurs (no base
           register writeback update) during execution.

      M3: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/CHDCBHEE.html
      M4: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0553a/CHDCBHEE.html
     
      Address     Name   Type  Required privilege  Reset value  Description
      0xE000E008  ACTLR  RW    Privileged          0x00000000   Auxiliary Control Register

      Auxiliary Control Register

      [0]    DISMCYCINT     Disables interruption of multi-cycle instructions.
             This increases the interrupt latency of the processor because load/store and
             multiply/divide operations complete before interrupt stacking occurs.

      M7: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646b/CHDCBHEE.html
      Does not have this bit.
     
  6. Like
    M-atthias got a reaction from lunakid in Bit-Bang USB on MSP430G2452   
    I could reproduce our headache in asl-assembly Mecrimus-B and finally found the bug !
     
    It occours if the last data byte finishes with five data-ones and D- low because of former data. Then the first low of SE0 triggers bit unstuffing in the first bit, the false bit unstuffing consumes another bit, which is the second low of SE0 in this case. So SE0 is missed completely.
     
    Simply add a SE0 check to unstuffing in first bit. There are enough clock cycles left for this purpose.
     
    I changed my macro
     
    unstuff macro register, bitmask
      bit r8, r12             ; [8]   Stopferkennung, 6 Bits nacheinander kein Wechsel !  Detect stuffing, 6 bits without change...
      jnz +                   ; [9]   Datenbits hier invertiert !                         Data bits inverted here !
                              ; [10]
     
      mov.b @r9, register           ; [e 1]  F
  7. Like
    M-atthias got a reaction from lunakid in Bit-Bang USB on MSP430G2452   
    Would you like a surprise ? A very special one indeed ?

    Mecrimus-B 0.4 runs on a MSP430F2012 with a 32768 Hz crystal !



    D+ with 50 Ohms on P1.0
    D- with 50 Ohms on P1.1

    Pullup with 1.5 kOhms for D- hardwired to Vcc
    Sync-LED on P1.2 (Anode with 100 Ohms) and P1.3 (Cathode)
    SMCLK for measurements on P1.4

    32768 Hz crystal on XIN/XOUT
  8. Like
    M-atthias got a reaction from jpnorair in Forth for fresh MSP chips   
    I wish you happy Easter, of course with a small surprise: I just conquered the MSP432P401R with Mecrisp-Stellaris and I wish to announce quite fresh ports of Mecrisp for MSP430FR4133, MSP430FR5969 and MSP430F5529. Enjoy :-)

    Matthias
     
  9. Like
    M-atthias got a reaction from igor in Forth for fresh MSP chips   
    Mecrisp is a native code Forth for MSP430 cores and Mecrisp-Stellaris runs on ARM Cortex M0, M3, M4. Forth is a programming language with two stacks and an extendable compiler which has been designed decades ago for controlling a radio telescope in astronomy and shows its strengths in microcontrollers, too. Its most interesting feature for embedded programming is that the compiler runs inside of the microcontroller and you basically chat with it over a serial terminal line or any other link you can imagine and implement. You can wiggle your wires manually, experiment with fresh peripherals and try every definition you wrote immediately. No need for the "change, assemble, flash and try" cycle. Great for hardware debugging !

    Here is "the" classic Forth primer if you wish to get an idea how language looks like: http://www.forth.com/starting-forthTraditionally, Forth has been implemented with a virtual machine, but both my compilers generate native machine code for speed.

    Matthias
     
  10. Like
    M-atthias got a reaction from tripwire in Forth for fresh MSP chips   
    Mecrisp is a native code Forth for MSP430 cores and Mecrisp-Stellaris runs on ARM Cortex M0, M3, M4. Forth is a programming language with two stacks and an extendable compiler which has been designed decades ago for controlling a radio telescope in astronomy and shows its strengths in microcontrollers, too. Its most interesting feature for embedded programming is that the compiler runs inside of the microcontroller and you basically chat with it over a serial terminal line or any other link you can imagine and implement. You can wiggle your wires manually, experiment with fresh peripherals and try every definition you wrote immediately. No need for the "change, assemble, flash and try" cycle. Great for hardware debugging !

    Here is "the" classic Forth primer if you wish to get an idea how language looks like: http://www.forth.com/starting-forthTraditionally, Forth has been implemented with a virtual machine, but both my compilers generate native machine code for speed.

    Matthias
     
  11. Like
    M-atthias got a reaction from jazz in Forth for fresh MSP chips   
    I wish you happy Easter, of course with a small surprise: I just conquered the MSP432P401R with Mecrisp-Stellaris and I wish to announce quite fresh ports of Mecrisp for MSP430FR4133, MSP430FR5969 and MSP430F5529. Enjoy :-)

    Matthias
     
  12. Like
    M-atthias got a reaction from bluehash in Forth for fresh MSP chips   
    I wish you happy Easter, of course with a small surprise: I just conquered the MSP432P401R with Mecrisp-Stellaris and I wish to announce quite fresh ports of Mecrisp for MSP430FR4133, MSP430FR5969 and MSP430F5529. Enjoy :-)

    Matthias
     
  13. Like
    M-atthias reacted to Lyon in Discovered TM4C1294 ADC silicon bug ?   
    Hi,
    The main problem with 129 series when migrating software is system clock setting, which changed a lot - new options for PLL settings at 320/480MHz - so check the system settings clock and to be sure it works correctly. But as no inside is available for measuring frequency, the best idea is to use either UART and see if working OK or a PWM generating a prescribed waveform.
    Also you can check the Tiva software, code is open. The example program qs-iot uses ADC, sample sequencer 3 to measure temperature.
    L
  14. Like
    M-atthias reacted to Lyon in Discovered TM4C1294 ADC silicon bug ?   
    Hi,
    ADC clock must be configured also (new in Tiva-129!) with the call: ADCClockConfigSet(ADC0_BASE, ADC_CLOCK_SRC_PIOSC | ADC_CLOCK_RATE_FULL, 1);   And this one can be read (from driverlib/adc.c) as (neglecting first some assertions):     //     // Write the sample conversion rate.     //     HWREG(ui32Base + ADC_O_PC) = (ui32Config >> 4) & ADC_PC_SR_M;       //     // Write the clock select and divider.     //     HWREG(ui32Base + ADC_O_CC) = (ui32Config & ADC_CC_CS_M) |                                  (((ui32ClockDiv - 1) << ADC_CC_CLKDIV_S)) ;   As you can see, all these are based on HWREG macro, defined in inc/hw_types.h as: #define HWREG(x)             (*((volatile uint32_t *)(x))) which I assume you know it. You may verify these and get additional code for your case. If you pre-process the above snippet, you will have an instant conversion of all constants or you can transform them into direct register access. L
  15. Like
    M-atthias reacted to Lyon in Discovered TM4C1294 ADC silicon bug ?   
    Hi,
    Please be careful - the excerpt in blue is part of the function mentioned above - you do not need to repeat again. I was trying to suggest you to read the code in driverlib, to see it is easy to decipher and then use.
    Now, I suggest again to read the comments of that function in driverlib. I recognize the user manual is/has some problems, but the main descriptions are in the followings:
    -paragraph 18.3.2.6 - Module clocking
    -paragraph 5.2.5.2 - page 247 ADC Clock Control
    But I use what is written in driverlib - used in several other situations without problems.
    L
  16. Like
    M-atthias got a reaction from bluehash in Loran-C radio navigation   
    Happy new year !

    I am happy to announce a software defined Loran-C longwave radio navigation receiver running on STM32F407 ! If you happen to live somewhere on earth with Loran-C signal coverage like Europe and parts of Asia, I would like to get in contact with you for beta testing out in the wild.

    The first experimental release is available now on download section on http://mecrisp.sourceforge.net/

    Best wishes,
    Matthias
     
  17. Like
    M-atthias got a reaction from bluehash in Bit-Bang USB on MSP430G2452   
    I just discovered the above Boot430 implementation out into the wild :-) Great !

    http://programmablehardware.blogspot.de/2013/11/homebrew-msp430-development-board.html

    Best wishes,
    Matthias
     
  18. Like
    M-atthias reacted to jscrane in Bit-Bang USB on MSP430G2452   
    Excellent work guys!
     
    I'd just like to add that I noticed the occasional communication failure from the uploader when it was breadboarded. Today I moved it to a piece of stripboard and haven't seen a single upload error since.
     

  19. Like
    M-atthias reacted to elpaso in Accessibility keyboard for impaired people   
    @@simpleavr
     
    I'm not an ASCII artist   , please check if it's ok:
    /* Schematics Note: decoupling CAP and LDO are not shown // VCC (3.3V) // | // +------+ MSP430G2452/ // _ _ MSP430G2553 // |1| |4| --------------- // |K| |K| | XIN|--+ // |5| |7| | | [ ] 32.768KHz XTAL (optional) // - - | XOUT|--+ // | | | | __o__ // | +---|RST P2.0|--o o---o LEFT \ // | | | __o__ | | // +----------|P1.0 P2.1|--o o---o UP | // | | | __o__ | | // | +---|P1.1 P2.2|--o o---o CENTER CLICK > Mouse controls // _ _ | | __o__ | | // |6| |6| | P2.3|--o o---o RIGHT | // |8| |8| | | __o__ | | // |R| |R| | P2.4|--o o---o DOWN / // - - _|_ // | | /// // USB D+ D- // // */ I've also added an XTAL string to the end of the string descriptor:
    #ifdef USE_32768HZ_XTAL static const uint8_t String_Descriptor_2[] = { 30, 30, 3, 'M', 0, 'o', 0, 'u', 0, 's', 0, 'e', 0, ' ', 0, '4', 0, '3', 0, '0', 0 , ' ', 0, 'X', 0, 'T', 0, 'A', 0, 'L', 0 }; #else static const uint8_t String_Descriptor_2[] = { 20, 20, 3, 'M', 0, 'o', 0, 'u', 0, 's', 0, 'e', 0, ' ', 0, '4', 0, '3', 0, '0', 0 }; #endif just to be sure I've built and uploaded the right fw.
     
  20. Like
    M-atthias got a reaction from elpaso in Bit-Bang USB on MSP430G2452   
    Good morning to Italy - I like your project a lot !

    Mecrimus-B already defines a mouse, it is constantly moving the pointer to the right, but adding buttons should be simple if you feel comfortable with assembly.
    Replace this sequence in Mecrimus-B-32768Hz.asm with button states - movements are 8-bit signed integers, moving to the left would be -1=255:

      mov.b #0, &Irq_In_Sendepaketpuffer+2 ; Buttons pressed
      mov.b #1, &Irq_In_Sendepaketpuffer+3 ; X movement
      mov.b #0, &Irq_In_Sendepaketpuffer+4 ; Y movement
      mov.b #0, &Irq_In_Sendepaketpuffer+5 ; Wheel movement

    Replace toggle_syncled with a 4 cycle nop, remove the clockout init code and change the PxDIR settings accordingly after Reset, and the debug signals are gone.

    toggle_syncled macro ; Preserve clock cycles if you want to remove this !
      xor.b #4, &P1OUT   ; Toggles Sync LED, good for triggering an oscilloscope and visual feedback
      endm

    toggle_syncled macro ; Preserve clock cycles if you want to remove this !
      nop2
      nop2
      endm

    Remove this: bis.b #010h, &P1SEL ; SMCLK an P1.4 ausgeben  SMCLK for measurements on P1.4

    Boot430 includes a lot of special code not needed for a mouse, and note that the bbusb package still contains a serious bug in its receiver code inherited from early Mecrimus-B, as this has been mostly a development shapshot. @@simpleavr Maybe you could repackage bbusb as a simple C starting point and replace the receiver with the Boot430's one which has the SE0-unstuff-bug fixed ?

    I understand that you are puzzled by now. USB support on MSP430 is still in an early stage, Boot430 is the first application and the most current piece which development is focussed on. Boot430 is based on the bbusb snapshots, and bbusb is an enhanced and improved C rewrite of Mecrimus-B, which is assembler only. I fixed all known bugs in Mecrimus-B, but it is a pioneer, and it has not received so much testing effort, high-level protocol support and functionality enhancements.

    Altough it will be possible in future, you have no choice but to use the 32768 Hz crystal for long-time stability at the moment. Mecrimus-B offers direct input of stable digital external 15 MHz or 18 MHz clock, but this is not what you search for.

    For a prototype, you can drop ESD protection, look at the pictures of my early msp430f2012 board and simpleavr's breadboard clone at the beginning of this thread to get an idea what is needed for a start.

    Best wishes for your project from Germany,
    Matthias
     
  21. Like
    M-atthias got a reaction from elpaso in Bit-Bang USB on MSP430G2452   
    Hello @@theprophet,

    if the crystal is in place, it helps to stabilize the DCO to 15 MHz by having a timer running in a software frequency locked loop which counts how many DCO ticks occour within one 32768/8 Hz tick and adjusts DCO in given direction. This helps in long time connections, as temperature changes which change DCO frequency are regulated away, but for the case of detecting, you can have the same check as in the crystal-free implementation, as the DCO will be in RSEL 15 tap, too. Personally, I would opt for an P1IE line bit check instead in both cases, as the target application might want to run with 16 MHz, which is also within the BCSCTL1 RSEL tap 15.

    Christian Starkjohann of V-USB has implemented a frequency locked loop on the USB protocol itself, basically every 1 ms there is a SE0 on the bus without transmitting a packet. This consumes a timer just as in the crystal variant and might be implemented by setting P1IE on the other USB line and checking for that if catching the sync pattern fails. This is called "Keep alive signaling" and occours always, not only after fresh connection as simpleavr uses this for initial clock setup. In Bootloader application, long time clock stability is not a concern, but if you are going to establish long-time connections as for your IR receiver, for example there may be a stream of warm air from ventilation with varying temperature that will cause the connection to break down over time.

    "Frames: On a low speed link, to preserve bandwidth, a Keep Alive signal is sent every millisecond, instead of a Start of Frame packet. In fact Keep Alives may be sent by a hub on a low speed link whenever the hub sees a full speed token packet." http://www.usbmadesimple.co.uk/ums_3.htm See USB specification for more info.

    The "USB Tinkerer" is simply a small tribute in this forum for those having advanced USB usage on MSP430 :-)

    Matthias
     
  22. Like
    M-atthias got a reaction from theprophet in Bit-Bang USB on MSP430G2452   
    Fine, one more issue solved.
    Yes, toggle_syncled can be replaced by a 4 cycle nop.
  23. Like
    M-atthias reacted to theprophet in Bit-Bang USB on MSP430G2452   
    Hello @@M-atthias,
    Thanks for all the information. I'm going to clarify a bit here :
    - the "heartbeat" led I mentioned is *not* the same as the toggle_syncled : I left the toggle_syncled on P1.2 (xor.b    #BIT2, &P1OUT), and the "heartbeat" led is something @@simpleavr introduced (a led connected between P2.6 and P2.7 without a resistor which constantly blinks as soon as the usb sie is initialized).
    - when I remove the heartbeat led (connected on P2.6/P2.7 without a resistor), the usb line levels aren't shifted anymore, and the PC on which the device has most difficulties in being recognized starts to correctly recongnize and talk with the device.
    - if I connect the heartbeat led between P2.7 and ground with a 330ohm resistor in between, the signal shifting does not occur anymore, and the device works fine on the problematic PC.
     
    I think this led between P2.6/P2.7 is giving signal level/quality problems.
     
     
    By the way, I if want to remove the led associated to toggle_syncled, what should the toggle_syncled macro be ? nop4 ?
     
     
    Thanks,
    theprophet.
  24. Like
    M-atthias got a reaction from theprophet in Bit-Bang USB on MSP430G2452   
    Pardon me, they are disabled:

      P2SEL = 0;
      P2DIR = BIT6|BIT7;          // indicator led
      P2OUT = 0;

    It is another magic:

    Led 1 is on P1.0, bit constant 1 which is generated by constant-generator-registers.
    Oscillator Pins are on P2.6 and P2.7, bit constant 64/128, which require real constants to be generated and have longer opcodes.

    The assembler code has cycle-accurate timing, and the toggle_syncled Macro is expected to run in 4 cycles, which is only possible with the lower 4 bits that can be accessed with the constant-generator-constants -1, 0, 1, 2, 4. With your choice for the LED pin you need 5 cycles. But no matter, there is a nop2 next to it in receiver which you can get a spare cycle from.

    I am a bit puzzled if heartbeat and my original syncled are the same, but I am sure you will find the issue with this info.
     
  25. Like
    M-atthias got a reaction from theprophet in Bit-Bang USB on MSP430G2452   
    Another option:

    Does an resistor of about 1000 Ohms in series with the LED solve the problem ? Maybe the flowing LED current is dropping VCC levels temporarily a bit, simpleavr often had signal level/quality problems.
     
×
×
  • Create New...