Jump to content


  • Content Count

  • Joined

  • Last visited

About Pradeepa

  • Rank
    Level 1

Contact Methods

  • Website URL

Recent Profile Visitors

475 profile views
  1. I tried the ELPtronic software. It does not say that it is connected. But when I try to read the Firmware version then I can see Device Manager getting refreshed and then I get 'Unknown USB Device' enumeration. Which is almost the same thing happened to me when I use Energia. I'll post a question in TI forums and see whether I can get the FET firmware for the MSP430-G2 board. Then I can try to flash it through JTAG.
  2. I tried to use CCS. There also the behavior is same. I'll try that application and see. But I think it is a firmware issue. I'm trying to find the firmware of MSP430F16x chip and write it to the device.
  3. I did some more digging on this matter. I checked the pin27 of the TUSB3410VF chip using a oscilloscope to see whether the clocks are properly coming. The CLK3410 signal is driven by the MSP430F16x chip and I wanted to check whether the firmware is running properly on that chip. The result was as I expected. When I first connected the device to the PC I can see a 12 MHz square wave signal on PIN_49 of MSP430F16x chip. But as soon as Energia try to download the firmware to the device the clock gets disappeared. That's why the 'USB Device Not Recognized' message is coming. So somehow during firmware download process I believe the FET firmware crashes. May be it's stuck in some ISR. I'm still checking on this. Does anyone know what is the firmware inside the MSP430F16x chip? Thanks.
  4. Hello, Today around 3~4 hours I have been trying to program my MSP-EXP430G2 launchpad using Energia. It looks like the FET in the board got bricked or something. When I connect the board to my Windows 8.1x64 machine it gets enumerated as the 'MSP430 Application UART (COM5)' which is good. But then when I use Energia to download a simple 'Blinky' example to the board it fails. It says, tilib: MSP430_Initialize: Could not find MSP-FET430UIF on specified COM port (error = 57) tilib: device initialization failed Also the device becomes 'Unknown USB Device (Device Descriptor Request Failed)' in the Device Manager. So it looks like the board tried to re-enumerate and failed to respond to USB Standard messages. I believe this is an issue in the FET which is populated in the board. Is there any way to flash the FET in the MSP430 Launchpad? I tried 'LaunchPadFirmwareUpdater2.0.exe' to upgrade the firmware. But it is also not successful. It cannot detect the MSP430G2XXX device which is connected in the board. There also the device enumerates as an 'Unknown Device' too. I have Googled this issue for last couple of hours and could not find a solution. I think the FET firmware is messed up. So I'm trying to re-flash the MSP430F1612 to fix the issue. If anyone has tried this please let me know. If you have suggestions they are also welcome. Cheers!!!
  5. Hello, I think it is a good place to post information about this library I prepared. It is a very simple NRF24L01 library. The library is in C and can be used for any hardware platform with very minimal change. Please feel free to comment and criticize. I tested this using Stellaris Launchpad. Projects using CCS are available in GIT repo. Blog post: https://unboxnbeyond.wordpress.com/2015/04/03/pdlib_nrf24l01-v1-01-a-portable-nrf24l01-c-library-for-multiple-hardware-platform-integration/ Git repo: https://github.com/pradeepa-s/pdlib_nrf24l01 Thank you!!!
  6. Hello All, Recently I was working with some MSP430 project on my MSP430G2 board. But suddenly the USB-UART connection started not-working. I sniffed P1.2 using a logic analyzer and it looks like the data is coming properly. But it seems that it is not propagating to the PC USB port properly. I used HW-UART by switching the jumpers also. I sniffed the pin 32 of the TUSB3410VF pin also. The signal seems to be coming to that location also. My logic analyzer can decode that. I assume the TUSB chip is gone or some driver issue. I installed the MSP430 Application UART driver. I tried on Windows 7x64 and Windows 8.1x64. But with no luck. The device gets listed in the device manager properly. So I believe the descriptors are also correct. In fact I checked the descriptors using 'usbview' tool. I believe the descriptors are stored in the TUSB chips 8051 MCU. That means part of the TUSB chip is working. Maybe the TUSB MCU firmware is corrupted. Can someone help me with this? Is there any other driver that I need to install? I don't have another MSP430 board at the moment. So any help would be greatly appreciated to solve the issue. PS: USB descriptors Device Descriptor: bcdUSB: 0x0110 bDeviceClass: 0x00 bDeviceSubClass: 0x00 bDeviceProtocol: 0x00 bMaxPacketSize0: 0x08 (8) idVendor: 0x0451 (Texas Instruments) idProduct: 0xF432 bcdDevice: 0x0100 iManufacturer: 0x01 iProduct: 0x02 iSerialNumber: 0x03 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: Full Device Address: 0x05 Open Pipes: 5 Endpoint Descriptor: bEndpointAddress: 0x82 IN Transfer Type: Interrupt wMaxPacketSize: 0x0040 (64) bInterval: 0xFF Endpoint Descriptor: bEndpointAddress: 0x03 OUT Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0xFF Endpoint Descriptor: bEndpointAddress: 0x83 IN Transfer Type: Bulk wMaxPacketSize: 0x0040 (64) bInterval: 0xFF Endpoint Descriptor: bEndpointAddress: 0x81 IN Transfer Type: Interrupt wMaxPacketSize: 0x0040 (64) bInterval: 0x01 Endpoint Descriptor: bEndpointAddress: 0x01 OUT Transfer Type: Interrupt wMaxPacketSize: 0x0040 (64) bInterval: 0x01
  7. @@pabigot Just for a clarification, Since the instruction is 0xE000. First 4 bits (MSb) are 1110 (ie. T2 encoding) and the other 12 bits are zero (imm11= 0). So that means it is jumping to (PC + 0) location. In other words it is looping. I hope that's how you come to the conclusion that it is an optimized idle loop?
  8. I don't think the LM4F120 contains a QEI module. The new Tiva microcontroller does. Check the DC2 register to be sure.
  9. What is the processor you are using? Are you saying that the instruction is 'B.N 0xe000'? If that is the case the PC will contain address 0xe000. Instruction encoding encodes the instruction based on many factors. When executing the branch instruction it is calculating the offset based on the current PC address. Then will select the encoding scheme based on that address. So if your label is 0xE000 then it will determine how much offset it needs. Then will select the encoding. (I think there are some other factors also) As you can see, the ARM® v7-M Architecture Reference Manual contains 4 encoding patterns with different offset values (ie: imm8, imm11, etc). Each instruction can only provide limited offset. So the processor needs different encoding. I hope this helped. -Pradeepa
  10. Hello, Just now I tried the whole process on my Tiva-Ware launchpad and I did not get any issue. I tried with toolchains I got from CodeBench (http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/) and also from launchpad.net (https://launchpad.net/gcc-arm-embedded). You do not need to do that. Even with that line it works. I was checking StellarisWare previously. This might be the issue. Try downloading the toolchains that I used (I added the links to make it easy for you). It may be an issue related to the toolchain. I tried with the archlinux (gcc version 4.9.1 (Arch Repository)) from https://www.archlinux.org/packages/community/x86_64/arm-none-eabi-gcc/ but it did not even compile. It looks like it does not know about -mcpu=cortex-m4. Moreover, the lm4flash version I used is, LM4Flash version 0.1.3 - Flasher for Stellaris Launchpad ICDI boards Copyright © 2012 Fabio Utzig <fabio@@utzig.net> Copyright © 2012 Peter Stuge <peter@stuge.se> Hope this would solve your issue. -Pradeepa
  11. I have tried building and flashing the qs-rgb binary to my Stellaris launchpad. It worked without any issue. Steps, Set up the arm-none-eabi toolchain. I used 'arm-2013.11-24-arm-none-eabi-i686-pc-linux-gnu' toolchain. But any newer versions should ideally work too. Set up the $PATH variable to point to the 'bin' directory of the toolchain. Clone the lm4flash application using 'git clone https://github.com/utzig/lm4tools.git' Build the lm4flash application using 'make' Navigate to 'qs-rgb' project folder in the Stellarisware/boards/ek-lm4f120... Run 'make clean' Run 'make' The binaries will be created in 'gcc' folder. Copy the binaries to the location of 'lm4flash' application folder. Connect the device. Run 'lm4flash qs-rgb.bin' (I hade to use sudo too) This should work without any changes.
  12. Just one thing I observed in the qs-rgb example 'Makefile'. There is a line, Try commenting that line. Are you using Stellaris launchpad or Tiva launchpad?
  13. I hope you are compiling the application from "StellarisWare\boards\ek-lm4f120xl\blinky" directory. I believe the button issue is related to some error in your configuration. Cannot say without checking the code.
  14. Hello, Based on the post I assume you are using Linux for the developments. Did you try building the project using Code Composer Studio? Are there any errors/warnings in your compilations? What is the command you ran to flash the binary to the firmware?
  15. @@Sahil @@lawrence_jeff, Recently I saw this post. Interrupt enabling was never hard for me. So I decided to give some time to figure out what the actual issue in your first code. I think you need to refer the User Guide of the API after going through the introductory lab sessions to get somewhat clearer view on these APIs. Under NVIC it is specifically mentioned, But in your code you have not done that. You have not enabled interrupts for PORTC. The workaround proposed works because within the "GPIOPortIntRegister" function internally it calls IntEnable() function. My working code looks like below, SysCtlPeripheralEnable(SYSCTL_PERIPH_GPIOC); GPIOPinTypeGPIOInput(GPIO_PORTC_BASE,GPIO_PIN_6); GPIOPadConfigSet(GPIO_PORTC_BASE,GPIO_PIN_6,GPIO_STRENGTH_2MA,GPIO_PIN_TYPE_STD_WPU); GPIOIntTypeSet(GPIO_PORTC_BASE, GPIO_PIN_6,GPIO_FALLING_EDGE); GPIOPinIntEnable(GPIO_PORTC_BASE, GPIO_PIN_6); GPIOPinIntClear(GPIO_PORTC_BASE, GPIO_PIN_6); IntMasterEnable(); IntEnable(INT_GPIOC); In addition to this code, I included the interrupt handler in the NVIC under 'GPIO port C' and referred to the handler as an 'extern function'. I think you know about that process. The difference between the 'workaround' and this method is that when you use "GPIOPortIntRegister" it will dynamically register the Interrupt handler. So the interrupt handler address will be stored in the SRAM. When the processor is actually catering to the interrupt it will have to fetch this address from the SRAM, which will add some latency to the code. But if you statically register the interrupt handler through the NVIC, then your flash will contain the required address and the processor do not need to fetch the address from the SRAM. Which will be fast. If we can save some more clock cycles, it is always better to use that method if the requirement permits you to do so. It will improve performance and save some power. Thank you.
  • Create New...