Usar extern es un mal hábito ya que es propenso a errores. El estándar C-99 proporciona una alternativa segura para extern. Debe escribir la función prototipo en el archivo de encabezado sin una palabra clave externa. Luego incluya el archivo de encabezado en ambos archivos C. El enlazador es responsable de vincular la función en diferentes archivos.

Ejemplo:

Archivo: custom_header.h

void SavePC(unsigned long);

Archivo: source_c_file.c

#include "custom_header.h"

void SavePC(unsigned long)
{
      ....
      ....

      ....

}

Archivo: user_c_file.c

#include "custom_header.h"

void someFunction(void)
{
.
.
.

__asm("    mov     r0, sp\n"
  "    bl      SavePC\n"
  "    bx      lr");

.
.
.
}

Algunas cosas que podrías ver

A menudo, el lenguaje ensamblador debe usar un nombre decorado con un guión bajo ("_SavePC") para referirse a una función C que se define en C sin un guión bajo ("SavePC"). (El nombre en lenguaje ensamblador de las funciones de C ++ tiene mucha más decoración).

Solo uso la palabra clave "extern" en variables globales, no en funciones globales, exactamente como describe Kanwar Saad.

¿Ha considerado tal vez escribir ese bit de código en C, en lugar de en lenguaje ensamblador, y dejar que el compilador maneje los detalles de la convención de llamadas? Los compiladores de C de hoy a menudo admiten una sintaxis especial que le permite escribir dichos controladores en C más o menos pura, a menudo con algo así como un especificador "__interrupt", pero los detalles exactos varían de un compilador a otro. (Es posible que, al igual que muchos compiladores de C más antiguos, el compilador que está usando ahora requiera escribir cosas como controladores de fallas y tablas de vectores de interrupción en lenguaje ensamblador, ¿ha considerado tal vez la actualización a una cadena de herramientas de C más moderna como GNUARM o YAGARTO que utiliza gcc?)

La secuencia

bl      SavePC
bx      lr

probablemente crea un bucle infinito. ¿Has considerado usar algo más como los controladores de fallas difíciles ya escritos y probados por otras personas? Tal vez intente con a b c d o e ? Si tienes suerte, al menos uno trabajará para ti.

Si ninguno de esos pequeños detalles ayuda, puedes considerar usar el siguiente proceso general:

Proceso general

Cuando quiero llamar a una función C desde algún lenguaje ensamblador, yo

• escriba un fragmento de código de prueba temporal "similar" en C: un código auxiliar que envía los mismos tipos de parámetros a la función y obtiene los mismos tipos de valores de retorno, pero tal vez falte alguna funcionalidad crítica.
• compílelo con la opción especial que produce un archivo de texto lleno de mnemónicos en lenguaje ensamblador
• copiar y pegar ese esqueleto en lenguaje ensamblador en mi lenguaje ensamblador
• Pruebe el sistema: ensamble, compile, vincule, etc. el código de prueba no modificado para asegurarse de que realmente compila, vincula y funciona de la manera que espero.
• Confíe el archivo de lenguaje ensamblador que se vincula correctamente al sistema de control de versiones (aunque todavía falte alguna funcionalidad crítica)
• Complete la funcionalidad crítica que falta.
• Probar el sistema. Invariablemente, descubro que algo se ha roto tanto que ni siquiera termina de vincularse.
• Vuelva a la versión de enlace correcto del código de ensamblaje
• Intente completar la funcionalidad crítica que falta.
• Repita hasta que sea lo suficientemente bueno para enviar.

sugerencias para programación mixta de C y ensamblajes

borrador de un libro sobre la programación en lenguaje ensamblador ARM