[SOLVED] sscanf call never returns

Go To Last Post
2 posts / 0 new
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I'm using sscanf trying to parse the response of an AT command sent to a GSM module. It's something very similar to the minimal working example that follows:

#include <stdint.h>
#include <stdio.h>
#include <asf.h>

int main (void)
 char    response[] = "+CGREG: 0,1";
 uint8_t n, stat;

 sscanf(response, "+CGREG: %hhu,%hhu", &n, &stat);

 return 0;

The problem is that sscanf never returns back. When I paused the debugger, this was the call stack:

> sscanfTest.elf! Dummy_Handler Line: 284 
  sscanfTest.elf! <signal handler called> Line: 284 
  sscanfTest.elf! _scanf_i Line: 284 
  sscanfTest.elf! __ssvfscanf_r Line: 284 
  sscanfTest.elf! sscanf Line: 284 
  sscanfTest.elf! main Line: 12 

I think there's an exception going on, and that would be handled by this Dummy_Handler, which is just a while (1) { }. Initially I thought it could a missing part of the C library, so I tried adding libc in the linker. I also tried to uncheck the nano.specs option, thinking that maybe sscanf required the full C library to work. Unfortunatelly, none of these work. I know there are some libraries needed when one intends to work with floating point numbers, which is not the case.

​I'm programming a SAMD21 microcontroller using Atmel Studio 7.0 and ASF. Interestingly, ssprintf works just fine.

So, if anybody has an idea about what can be the causing this problem, I appreciate. Thanks!

This topic has a solution.
Last Edited: Fri. Sep 16, 2016 - 01:25 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just figured out the problem. The %hhu specifier in the format string was introduced in C99, and the C library used in the GNU ARM Toolchain (Newlib) doesn't support C99 formatting (at least not until version 2.1.0, used in Atmel Studio 7.0.634). Here's a thread in the Newlib's mailing list about this problem:



In my example code, sscanf works just fine if we change the type of the uint8_t variables to uint16_t, and set the specifier as %hu. So I think that's the simplest solution to the problem so far.