Jump to content
43oh

M-atthias

Members
  • Content Count

    69
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by M-atthias

  1. 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, STM
  2. 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
  3. 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
  4. Main Clock tree in section 5.2.5.2 shows a direct PIOSC line to the ADC CS, just as expected. Finally, section 15.3.2.7 gives an hint: 16 MHz PIOSC. Using the PIOSC provides a conversion rate near 1 Msps. To use the PIOSC to clock the ADC, first power up the PLL and then enable the PIOSC in the CS bit field in the ADCCC register, then disable the PLL. Stange procedure, but now it finally works. Thank you for pointing me to the right section ! Next release of Mecrisp-Stellaris will finally include an ADC example. PS: Mecrisp-Stellaris is written in bare metal assembly and not compatible wit
  5. In section 15.4 "Initialisation and Configuration" of chip datasheet nothing is said about the need to set clock registers. But I tried nonetheless: #define ADC_CLOCK_RATE_FULL 0x00000070 #define ADC_CLOCK_RATE_HALF 0x00000050 #define ADC_CLOCK_RATE_FOURTH 0x00000030 #define ADC_CLOCK_RATE_EIGHTH 0x00000010 #define ADC_CLOCK_SRC_PLL 0x00000000 #define ADC_CLOCK_SRC_PIOSC 0x00000001 #define ADC_CLOCK_SRC_ALTCLK 0x00000001 #define ADC_CLOCK_SRC_MOSC 0x00000002 #define ADC_CC_CS_M 0x0000000F // ADC Clock Source ADCClockConfigSet(ADC0_BASE,
  6. This is all my hardware startup code accompanying the example above. All other IO registers are on Reset default. movw r1, #0x7FFF @ Activate clock for all GPIOs ldr r0, =RCGCPIO str r1, [r0] movs r1, #1 @ Activate clock for UART0 ldr r0, =RCGCUART str r1, [r0] movs r1, #0x11 @ Set special function for PA0 and PA1 ldr r0, =GPIO_PORTA_AHB_PCTL_R str r1, [r0] movs r1, #3 @ Set special function for PA0 and PA1 ldr r0, =GPIO_PORTA_AHB_AFSEL_R str r1, [r0] @ movs r1, #3 @ Set special function for PA0 and PA1 ldr r0, =GPIO_POR
  7. Clock source for this failing example is 16 MHz PIOSC, which is default for ALTCLKCFG, which is default for ADC clock on TM4C1294. I already checked for those 16 MHz by generating an interrupt driven square wave with Systick timer. PLL and MOSC XTAL are off, UART0 is running on PIOSC, too. Tivaware examples unfortunately are of limited help for me as the calls diffuse within a huge library - I already banged my head against the adc.c in driverlibs. Do you know "direct register" examples for TM4C1294 ? Matthias BTW, off-topic: I found out that the simple ethernet transmit descriptors are non
  8. Dear Stellaris geeks, I am porting code from LM4F120 Stellaris Launchpad to TM4C1294 Tiva Connected Launchpad. I found the literature SPMA065 "Differences Between Tiva C Series TM4C Microcontrollers" which states that analog-digital converters in TM4C1294 only add features relative to TM4C123 / LM4F120. But I cannot make my ADC code work. To nail it down I have done this minimal example code in Forth (Mecrisp-Stellaris 1.1.5): $400FE638 constant RCGCADC : init-analog ( -- ) $1 RCGCADC ! \ Provide clock to AD-Converter \ PIOs already activated in Core 50 0 do loop \ Wait
  9. Frequency accuracy depends on how far off your crystal is. The closer the crystal matches the frequency, the finer the available calibration steps are. On my STM32F407 Discovery, the crystal is 74ppm too fast. Besides from this, the simple convolution receiver code included has 1 us time steps, but could changed for more precision at cost of more calculation time. eLoran enhancements are currently not included in first release :-) This is a basic old-style Loran-C receiver to be build with a common STM32F407 board and a longwave antenna. For eLoran all-in-sight recording we would need (much)
  10. Happy new year ! Loran-C radio navigation now runs on STM32F407 - thank you for the hint. As this will be a bit off-topic here I announced it on Stellarisiti: http://forum.stellarisiti.com/topic/1807-loran-c-radio-navigation/ Matthias
  11. 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
  12. 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
  13. I have done a similiar experiment while writing Mecrimus-B. I adjusted DCO settings manually with a frequency counter and connected to USB. My observation was that I could break the connection due to DCO frequency change by touching the chip with a warm finger or by breathing against it.
  14. 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 t
  15. Fine, one more issue solved. Yes, toggle_syncled can be replaced by a 4 cycle nop.
  16. 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.
  17. 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 pi
  18. Have you disabled the oscillator pin special function bits in P2SEL ? I cannot find P2SEL in your sources. They are enabled on Reset and may give you strange oscillator fault interrupts depending on external wirings when not switched off properly.
  19. Yes, you can do that. My first experiments had a digital external clock on XIN from 18 and later 15 MHz crystal oscillators.
  20. 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 mi
  21. You have done a great piece ! Don't forget to add yourself to the changelog, this way your work will be remembered. In the release package you should also include ready-to-run hex files for both timing variants for everyone - for convenience and to check if own compiler output is identical. > @M-atthias For the moment, detecting whether we are in bootloader or not with a crystal is not implemented. I have seen your comment, but I am currently deeply involved in doing laser spectroscopy and digital holographic microscopy for my PhD research and out of time. And finally: @@bluehash I high
  22. For bootloader usage, the USB lines will be most likely soldered to an USB connector, I don't think that it will be a big drawback for checking the D- line in P1IE and branch on that. If the target application is using USB itself, it could reuse the available Bootloader-USB-Interrupt-Handler and simply add its own buffer processing and protocol handling.
  23. Congratulations for solving this tough issue. Instead of checking DCO for 15 MHz, I would check if the interrupt on USB line is enabled in PxIE. Having a crystal or not is a hardware design question, I think it is ok to just supply two bootloader Hex files, one with, one without 32768 Hz crystal.
  24. In assembly, this is something like this: dint - jmp - In the file bbusb_protocol.c is "ProtocolSetupPacket", with a minimal implementation of request handlers. I suggest inserting a default block for both class and normal requests, and see if an unhandled packet comes in before the usbSetReport fails finally. I suppose you already know Wiresharks ability to sniff USB packets, too ? http://wiki.wireshark.org/CaptureSetup/USB At the moment, I am puzzled, too. Matthias
  25. Recently I have ported Mecrisp, a native code Forth for MSP430, to ARM Cortex chips. Currently it is running on LM4F120, STM32F407 and KL25Z128. As the core is written entirely in assembler, simply have a closer look on Mecrisp-Stellaris to get assembler examples. http://mecrisp.sourceforge.net/ For me, it would be interesting if Tiva chips are binary compatible with the Stellaris Launchpad - does the LM4F120 binary image run on the Tiva Launchpads ? Matthias - the same as in 43oh PS: Search for the Thumb-2 supplement reference manual !
×
×
  • Create New...