GrumpyOldPizza

I beg to differ there. Unless you just set up GPIOs using the library functions are a PITA. You never know what registers are actually touched in what sequence. There are so many undocumented side effects. Usually I spend more time reading the driverlib source to figure out what is really done by what function, that it would have taken me just write write direct register accesses. Hence the idea of "makes code easier to read" is at least for me quite the opposite. - Thomas

I had posted some bare metal code here to do exactly what you are doing with a HC-SR04: http://forum.stellarisiti.com/topic/2027-hc-sr04-ultrasonic-sensor-bare-metal/. So you might want to take a peek there. - Thomas

I got a curious question, perhaps somebody can help me out. If I write a 0x00 to BASEPRI, than all interripts are unmasked. If I write a 0x80 all interrupts that have a PRIO of less or equal to 0x80 are masked. So far so good. The TM4C really implements only 3 bits of priority, so the LSBs should not matter. But what happens if I write a 0x01 to BASEPRI ? Will that mask ALL interrupts that have a PRIO of less or equal to 0x01, which means all interrupts on a TM4C ? - Thomas

Why ? I needed a file system for a SDCARD where I could do low latency logging for some of my projects. There did not seem to be one fitting the bill. What ? RFAT is a FAT file system that is mean to be robust and fast, rather than to focus on the smallest possible size. Here the quick link to the source for the impatient: https://github.com/BizzaBoy/RFAT Now to some details. The source includes a port for the TM4C123GXL Launchpad, along with support for RobG's Color TFT BP. There is a simple, trivial example included that writes out 32MB of data to a file in 512 byte chunks

I see. That is gonna be more tricky. How do you set up your isr vectors ? If I'd know how, I could try and work out some boot code. There are a bunch of problems with this approach you are trying to take, so mind asking as to why you want your .text section in RAM ? Again, if you attach the project files I could quickly fix that (you are on TM4C123 ?)

Off for the weekend ... "German Reunification Day" ;-) Mind quickly posting your link script ? There are a few things that sound fishy. First off the "sp" is the content of memory location 0x0000000, not the value 0x00000000. Same goes for your PC. I am also a tad surprised about the "linker locates everything in ram". If it does so, how does the reset know that it's in RAM ? Usually execution starts from FLASH, and then ".data" is copied from flash, and ".bss" is zeroed out. Now TM4C can map the internal ROM to address 0x00000000 (see RMCTL), but not the internal RAM (unlike

JLINK will not work with Ecplise (unless you have a special pluging). The normal one issues a couple of commands to the gdb-remote that the jlink gdb server does not understand: monitor delay monitor halt monitor reset monitor reset halt (I don't claim to know which one of the 4 combinations is at fault ;-)). It's also possible to configure an "extended remote". In that case eclipse uses the "run" command to tell gdb to restart. I suspect that this will not allow breakpoints across a reset. But I might be wrong. Perhaps checking this eclipse box might help. - Thomas

I have never tried this with exclipse, but with gdb (using openocd): monitor halt load <your file>.elf monitor reset halt file <your file>.elf break <your reset handler> c You might get away without the "file <your file>.elf", for me that's just an extra insurance. Also the command "monitor reset halt" seems to fail some times, so you need to issue it again if it fails the first time. One big issue with gdb is that it does not know where the "sp" is after reset. It assumes all registers are undefined. Thus you need to explicitly load the "sp" as the

The case sensitivity is a pisser. You can solve that possibly via include paths to differentiate. I had not thought about this as I am not using Windows for those things. BSPCAM proably does more than just having a fixed system_TM4C ;-)

The ones for TM4C129X are not available yet. The ones for TM4C are (and the older LM3S/LM4F devices) available: http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/908/4212.svd_2D00_tiva_2D00_11073.zip What you do is: #include "TM4C123xxx.h" #include "tm4c123xxx.h" The upper case file will get the CMSIS type definitions (like structs for devices), and the lowercase one will get the bitfield definitions. There is of course system_TM4C.c which needs some work (mainly in config_TM4C.h). If somebody is interested I have a simpler system_TM4C.c wh

Kind of interesting. I had assumed from previous notes that it's basically a R7 with NVIC bolted on. But it has a 6 stage pipeline instead. The nice thing is that it has IEEE754 DOUBLES (yeah !). Not sure who will put this on a SOC. It's got a 64-bit AMBA AXI interconnect, which you had to use for hooking up FLASH & SRAM and DMA. It's assume this would mean a lot more gates than a AHB-Lite setup ... - Thomas

I am not really using an IDE ;-) The tools chain is gcc from https://launchpad.net/gcc-arm-embedded. Typically I use emacs/gdb for editing/debugging. When I want to impress folks from the Arduino crowd I fire up Eclipse (with said gcc toolchain), or Energia (which uses the same tool chain). - Thomas - Thomas

Ah, yes ... it's in 7.5.1.2 ... Here is a link to a forum that has the version of the spec that you are interested in. http://forums.parallax.com/showthread.php/146864-4-bit-SD-interface. The releasing CS works. I am using that with RobG's TFT/SD boosterpack. The TFT can be updated while the SD card is busy. My point was more along the line that you might spend 1ms to write a bunch of data and then spend 100ms or more waiting for it to be idle again. And the problem with the waiting is that there does not seem to be a good way to offload the CPU from polling. Regarding the DMA, I did

Sorry to pester this thread, but here some food for thought. First off my comment regarding the clock training was wrong, bad memory. 6.4.1.1 states that 74 clocks (@ 400kHz) are needed with CS tied high. 7.2.1 is clear on that CMD0 with CS tied low triggers the switch to SPI. Perhaps that is part of my problems, as with RobG's TFT/SD there are clocks at more than 400kHz as the TFT in my case is active before the SD Card gets initialized, as the SPI bus is shared. So perhaps the init-sequence has to be split, so that the 74 SPI clocks @ 400kHz and CMD0 are send right away before anything e

I was more after "how does the ROM code know where the uDMA control structure is located" ... Mainly, because I tend to do most of the coding bare metal, but to be honest for setting up things it might be a waste ... Guess the naming is unclear in the code. An SD Card comes up in SDBus mode. This initial sequence switches it's interface over to SPI. If the SD Card was already in SPI mode, this is a noop. There is no SD Card reset sequence ... So if your MCU resets in the middle of a read or write sequence, you have to deal with that another way. You need to send the extra 2 b

Pretty cool. Working on that for my own FAT File System as well (after I figured out why I get every now and then a 200ms delay from the SDHC Card I am using). Couple of questions/comments: (1) You might want to use SSI_FRF_MOTO_MODE_3. The way MODE_0 works causes an extra clock cycle to get the SCLK/MOSI lines back to idle signal levels. Hence you are running at 88% of the max throughput. (2) Where does the ROM allocate the space for the uDMA control structs ? Hardcoded, or dynamic throu some wrapper ? (3) Keep the drive strength at 4mA. The SD spec would actually lead you to

Here some quick and dirty I2C/MPU6050 files. I am using bare metal, so there is not a lot of overhead. The interrupt handler and the enable/priority assignment is done by the RTOS I am using, so it's missing here. The only other RTOS feature used is that the ISR wakes up the calling task (wai_flg/set_flg). I could read the data off the MPU6050 with 1kHz sample rate. Perhaps that will got you going quickly faster. - Thomas lm4f120_i2c.c lm4f120_i2c.h mpu6050.c mpu6050.h

Thanx for posting that. Nice work. Now something that's always made me curious. On the TM4C123 launchpad, is there a way to hook up a separate VBAT somehow, say from a coincell, so that the RTC in the hibernation module keeps on running ? Why ? Well, I have a microSD attached, and would like to get a reasonable time/date set ... - Thomas

AWESOME. Do you use the GPS's COG or a compas heading to determine direction ?

Odd. 9 is what the reference manual says as well for 400kHz. Just to be sure, you did not enable high speed mode in either I2CMTPR or I2CPC ? This would change how TPR is used as a frequency divider. How do you measure the frequency of SCL ? Have you measured another clock to make sure your CPU is running at 80MHz (yes, I screwed that up once ...). I am asking because if your CPU runs at 120MHz (like them TM4C129) and you used high speed mode and TPR of 9 ... then you'd see 2.0MHz on SCL ... - Thomas

- USB OTG connector (there is just the one for the STlink) - the boards all run off the internal precision oscillator, so you have to rework/upgrade them to get precise clocks (needed for USB/CAN)

Lyon, the embedded flash is of course the other option. 100k read/write cycles ... Perhaps using a set of 16 1k pages to circle throu ... Doesn't seem to be a biggy. On the Lego Mindstorms NXT they put a file system in the flash ... So yes, not a big deal. The EEPROM just seemed to be there and waiting to be used ;-) The issue with internal flash though is that you need to execute the code that writes it from RAM, and hence you have to block all interrupts while doing so. Your observation about the errata is interesting. Most people don't even read them. My choice of TI is mainly the f

Yes, in this code "speed" is the bitrate, i.e. 400kHz. SystemCoreClock is for me 80000000 for the EK-LM4F120XL.

Lyon, thanx for pointing out. I was after bare metal, not driverlib ... Perhaps I'll just go ahead and grab the bits I need. Would have been simpler if there somebody had done that already. The multiple of 4 ... It's for configuration data. I'd assume that the EEPROM will be divided into a single struct that contains the config/calbibration data of my system, and a 2nd set that contains way points and such. Padding that to multiples of 4 seems trivial. The errata in the TM4C part still seem to be relevant: "EEPROM Data May be Corrupted if an EEPROM Write or Erase is Interr

Has anybody tried to use the EEPROM ? I had been looking at the errata, and I am not sure this is usable ... Is there good bare metal code out there to simply read the whole eeprom in one chunk, and write it in one chunk ? What do I need to look out for ? I'd love to use this for my rover, to store configuration and waypoint data ... - Thomas