User login

Weekly Report




After the last project meeting, we decided to ditch contiki as it does not offer much that will be useful to this project. Rather than trying to hack in a new mac controller and modify the existing mac data path, it is going to be easier to just write something from scratch. The future plan will be to add networking layers on top.

In order to facilitate a new platform, we're sticking with the CC2538DK. I've spent a bunch of time getting a linker script, start up file and some basic code running. So far I've got the LEDs, UART and LCD working fine. The next step is to try and get libc (specifically newlib) going to add support for things like printf, malloc and free. Printf is extremely useful for debugging and it makes the project much simpler to implement. Malloc will be useful for packet buffers and the like (although static memory could be used instead).

Unfortunately calling printf causes a hardfault. We don't even manage to get through newlib down to the stubs that are environment specific (the part that takes the characters from printf and passes them to the UART). Using GDB, we can examine what caused the hardfault and go about debugging from there.

I have no idea why, but I am unable to read any of the useful registers. It seems like the GDB server provided by TI (which gdb connects to) doesn't like hardfaults and somehow locks us out of some registers. This is a big problem, as I need to be able to debug the CPU in order to get anything done. I've lodged a support request with the TI forum: I don't have very high hopes as I haven't had very good support in the past.

I'm really hoping that Dean (as he has a lot of experience dealing with ARM Cortex M3 parts) is able to help me solve this. It's hard to debug without printf and without gdb!