在Linux上构建示例

4个帖子/ 0个新
最后发表
ratsept
离线
最后看到:6年2个月前
加入:2015-04-13十43
在Linux上构建示例

你好,

我刚刚开始试验DA14580,我似乎处处碰壁。我按照AN-B-024的指示,花了一整天的时间来追逐奇怪的问题,试图在Ubuntu上用GCC构建和示例,但仍然没有运气。我似乎已经到了一个点,代码编译,并得到什么似乎只是ROM链接仍然失败的链接阶段。

我从DA14580_581_SDK_3.0.8.0/dk_apps/keil_projects/proximity/prox_reporter示例开始,并使用转换器脚本生成Makefile。我删除了奇怪的树优化标志,并修复了汇编文件扩展名(*)的问题。s和*. s)。还有一些Keil特定的编译器魔法(__INLINE vs static inline…),但现在我真的卡住了。似乎这个例子是在ROM中引用代码,无论出于何种原因,都在SDK附带的符号表中进行了注释。

这是make的链接部分输出。
>>>
链接/ full_emb_sysram.axf
./…/…/ /src/plf/refip/src/arch/main/ble/jump_table.o:(jump_table_mem_area+0xb0): undefined reference to ' ke_task_init_func'
./../../../ src / plf / refip / src / arch /主/祝福/ arch_main。在函数' main_func'中:
Arch_main.c:(.text.main_func+0x88):对' patch_llc_task'的未定义引用
/…/…/ /src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x4): undefined reference to ' l2cc_pdu_recv_ind_handler'
/ / / /src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x8): undefined reference to ' smpc_send_pairing_req_ind'
/src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0xc):未定义的“smpc_check_pairing_feat”引用
/ / / /src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x10):未定义引用' smpc_pairing_cfm_handler'
/ / / / /src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x14):未定义引用' my_llc_con_update_req_ind'
/ / / /src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x18): undefined reference to ' my_llc_ch_map_req_ind'
/ / /src/plf/refip/src/arch/main/ble/arch_patch.o:(.rodata.patch_table+0x1c):未定义的引用' patch_gapm_adv_op_sanity '
/usr/bin/../lib/gcc/arm-none-eabi / 4.9.3 /../../../../ arm-none-eabi / bin / ld: / full_emb_sysram。隐藏符号' smpc_pairing_cfm_handler'没有定义
/usr/bin/../lib/gcc/arm-none-eabi / 4.9.3 /../../../../arm-none-eabi/bin/ld: final link failed:错误值
Collect2: error: ld returned 1 exit status
Make: *** [out/full_emb_sysram。错误1
<<<

Ke_task_init_func似乎在符号文件中,但被注释了。
patch_llc_task存在于SDK中的一个对象文件中,但链接重叠了一些代码,所以我不确定那里发生了什么……

你能给我指出正确的方向,或者至少给我一个提示,哪个例子最适合测试我的系统。从我所读到的,人们在GCC和你的芯片上没有太多的运气,但是因为我们已经使用了一堆不同的BLE soc,并且在经历了一些痛苦之后,我们已经能够让它们工作,我还不想放弃。既然你有了那个appnote,并且似乎已经投入了一些努力来支持GCC,也许还有希望。当我们得到一些有用的东西时,我会很高兴地开源我们的努力。

关键词:
JE_Dialog
离线
最后看到:3个月20个小时前
工作人员
加入:2013-12-05 14:02
你好,我会诚实地说

大家好,我要诚实地指出,目前我们还不能在580上提供广泛的GCC支持。我们刚刚宣布的下一个平台(680)将会有所不同,但除了我们在GCC上一对一支持的几个客户之外,我们现在还不能以一对多的形式提供支持。如果这不是你想听到的,我很抱歉,但我更愿意诚实,不要设定不切实际的期望。BR JE_Dialog

JE_Dialog
离线
最后看到:3个月20个小时前
工作人员
加入:2013-12-05 14:02
你好,我会诚实地说

大家好,我要诚实地指出,目前我们还不能在580上提供广泛的GCC支持。我们刚刚宣布的下一个平台(680)将会有所不同,但除了我们在GCC上一对一支持的几个客户之外,我们现在还不能以一对多的形式提供支持。如果这不是你想听到的,我很抱歉,但我更愿意诚实,不要设定不切实际的期望。BR JE_Dialog

ratsept
离线
最后看到:6年2个月前
加入:2015-04-13十43
这真是个令人伤心的消息。我

这真是个令人伤心的消息。我真的觉得我非常接近构建这个示例(尽管我不知道它是否实际上可以在任何硬件上运行)。我也不反对一对一的帮助,如果你能做到的话。我要怎么做才能得到这样的帮助?我确实有一些项目即将进入批量生产,如果这是你所追求的,但现在我们的大部分工作都是用北欧soc做的(价格和功耗是我们试图用你的硬件优化的东西)。

我什么时候可以看到680系列的样品和开发工具?我真的很有兴趣尝试尽可能多的不同的解决方案,因为我们做了很多BLE原型设计,需要尽可能多地掌握一切。