前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >NUC505 - HS USB

NUC505 - HS USB

作者头像
用户2366192
发布于 2021-05-31 03:06:37
发布于 2021-05-31 03:06:37
1.2K00
代码可运行
举报
文章被收录于专栏:TopSemic嵌入式TopSemic嵌入式
运行总次数:0
代码可运行

背景

本来做的是M484,看好了它的片上高速USB、双SDHC、QSPI FLash等,结果入了新塘第一坑:LQFP64封装是.4间距的,偶直接拖了个STM32F205的封装过来,.5间距的,结果就是下面这样:

M484 -> NUC505

无意间于Whycan论坛(原填坑网)上发现了这款神U:NUC505:

  • 高速USB Device,USB2.0 USBHost. SD Host.
  • 128 KSRAM,512KB/2MB SPI Flash(片上无flash)
  • 含有浮点运算单元和DSP的ARM® Cortex®-M4内核,最高可运行至100MHz
  • 内建双声道24位音频解码器(某些型号)
  • 封装友好:LQFP48、QFN48、LQFP64、QFN88.

相见恨晚啊,这不就是我一直想要的嘛.. 天猫Nuvoton旗舰店一查价格:NUC505DL13Y(2MB SPI FLASH)才¥7.60!便宜的令人发指!!!那还等什么?立马画板打板,开启了我的“坑”中之旅~~

先记录下官网用到的软件及文档:

  • BSP:NUC505_Series_BSP_CMSIS_V3.03.001.zip
  • MDK Pack:Nuvoton.NuMicro_DFP.1.3.5.pack

坑一:J-Link不支持?

明明是CortexM4核,明明也支持SWD模式,结果JLink无法识别,打开J-Link commander也没NUC505系列,估计是没给Segger付费吧,可惜了我的MiniJlink和RTT,好用的工具只能暂时放一边了,好在之前参加过几次Nuvoton的研讨会,大方的新塘送的demo板上都有NuLinkMe调试器,暴力掰下来,然后杜邦线连之。

Nuvoton Demo Board

坑二:片内SPI Flash And Boot

前面多次提到过2MB的片内SPI Flash,2MB看上去很美,但是封的是SPI FLash,虽然支持片上运行,但是速度相比SRAM中运行慢了100倍!没错,是100倍!星爷的那句 “我奶奶骂他欺善民,反被他捉进了唐府,xx了一百遍 !一百遍!!!” 在耳边飘荡…, Github中看到了下面的描述:

“ Although code can run directly out of the SPI flash, execution is understandably SLOOOW. For this reason, the default Section Placement setting provided for new projects by this package is “Flash Copy to RAM”; however, the usual “Flash” and “RAM” options are provided for completeness as well. The NUC505 has a “Boot from USB” mode where the device appears as a USB Mass Storage device. A .bin binary image copied to the device is programmed to the internal SPI memory at 0x0. When the NUC505 is then returned to the “Boot from Internal MCP SPI flash” and restarted, it will attempt to boot from that image. HOWEVER, the “Boot from USB” USB Mass Storage implementation appears to only work in Windows; Linux detects the emulated volume as having corruption and will refuse to mount it for write access. When the NUC505 is set to its “SWD/ICE Mode with Internal SPI Flash“ mode, the NUC505 will NOT execute user code upon hardware reset. Instead, it runs from its internal mask ROM code and execution eventually reaches an endless loop. This boot mode seems to be intended exclusively for using an IDE to both program memory and specifically initiate debugging execution of the user application.”

片上的spi flash看来只能用于代码的存储和boot了,(还可以用于存储一些数据,省了外部的存储了)然后将代码copy到ram里运行,也行,谁让它便宜来,128KB SRAM,分了4个bank,每个32KB,这样就可以作为32K RAM/96 K Flash 或者 64K RAM/64 K Flash的配置来用了,紧着这128K 来回蹂躏吧~

But,在“SWD/ICE with Internal SPI Flash”模式下无法运行用户代码是什么鬼?尝试了才知道:在这种模式下,可以通过MDK的debug进行程序下载、debug、查看变量、全速运行等等,但是退出debug模式,这货就不跑了!即使按reset也不行,想让它从能从spi flash中自举运行?那得改变它的硬件boot模式才行!只有1111模式下可以直接从内部SPI Flash启动,但是在这种模式下,仿真器无法连接!!!真是反人类的设计!!不服?咬他?当心被捉进唐府

记NUC505的启动配置:(在复位时默认上拉,所以如需配置为0,则相应管脚需加10KR电阻下拉)

记录我的板子上的调试:

  • 电阻全都不焊,默认 1111 :从片上SPI Flash中启动
  • R13 = 10KR, PB4=0, SWD/ICE + 内部SPI Flash ,调试时使用这种模式。
  • R3 = 10KR, PA9=0, USB启动。

坑三:优化精简代码

官方代码:NUC505_Series_BSP_CMSIS_V3.03.001,压缩包52M左右,解压后先看下Readme.pdf,比较详细的描述了各个目录下的工程等,为了方便备份,我又完整的拷贝了一份解压后的文件,打开NUC505_Series_BSP_CMSIS_V3.03.001\SampleCode\StdDriver\USBD_VCOM_SerialEmulator这个工程,然后开始编译+删除,不断尝试后把不需要用到的都给删除掉并能编译成功,至文件夹大约5MB左右,OK!这就是我要的工程了,以后就在这个上面盖房子就行。

注:默认配置该工程是使用的SPI FLASH的,需要先设置成“SWD/ICE + 内部SPI Flash”模式下,debug下可以运行,也可以下载,然后把启动模式更改为“内部MCP SPI FLash启动”,上电即可运行。

在SampleCode\BootTemplate下有几个例程,参考来实现如何使用SPI Flash和SRAM,目前使用MainOnSram例程,就是启动代码在spi flash中,然后其他大部分程序都是在ram中执行。直接用该例程的ld文件就可以。另外程序稍作配置,将主频配到180M,96M太对不起这内存了。顺便移植了下新塘的NuConsole,跟Segger的RTT类似,在debug模式下打开即可,再插上shell的翅膀,可以起飞啦!

NuConsole

顺便再吐槽下他家的NuConsole,虽然功能跟RTT相似,结果请看上图:不支持最大化!只能这么小窗口显示,真是小气的很~

坑四:新鲜出炉的M484+NUC505

之前由于封装画错了的M484只能含泪默默重新改版,顺便把NUC505也改了改,加上了oled和按键。

M484Nuc505

NUC505 LQFP封装的可用IO 还是比较少的,目前几乎全用上了,于是在按键输入上又掉坑里了!

PA0 - 看上去是GPIO管脚,结果该脚使能上拉读出来的值始终为0,查了下手册才发现PA0-ADC_CH0,内建10KR电阻分压用作电池检测!内贱啊!!!也没个电路看看如果要测电池电压该怎么接…顺便看了下它的ADC,虽然只有一个ADC,可是玩出了很多花样:

  • ADC_CH1通道最高可达1MSPS的采样率。
  • ADC_CH2~ADC_CH7:最高200KSPS采样率。
  • ADC_CH2:支持键盘比较器。
  • ADC_CH0:内建10KR电阻分压用作电池检测。

好在OLED一把就点亮了,SPI代码配置真是简洁。

坑五:VCP 512整数倍发送的问题

老生常谈的话题了,早在STM32上就有这问题,结果在505上又遇到了,说白了就是在发完整数倍数据包如果还有要发的数据就接着发数据,没有要发的数据了就发个空包就行,在这一点上Nuvoton设计的还是比较人性化的: USBD->EP[EPA].EPRSPCTL = USB_EP_RSPCTL_ZEROLEN; 对EPRSPCTL的ZERO位置1就会发送一个空包了。至于为啥是512,因为是高速USB嘛,还有一点:可以配置缓冲区为1024,然后收发 一包就是1024Byte,真爽~

坑六:UART的接收超时中断

之前用stm32F072时使用串口空闲中断作为接收成帧判断,看NUC505的手册看到UART_TOUT寄存器中的TOIC:当RX FIFO接收到一个新的数据时,定时溢出计数器开始计数,超时后如果RXTOINT为使能,则接收超时中断RXTOINT产生。要求设置为40~255之间,如TOIC为40,则在4个字符时间长度后还没收到新数据,则超时中断产生。看这个描述正正合我的心意!UART1设置46字节fifo的阈值中断,这样使用也可以很大的减轻CPU的负担又能再收到一帧数据后 延时4个字符给出中断,测试时也是OK的,蛋蛋蛋但是:

当正好发送46字节时,则无超时中断产生,只有UART_INTSTS_RDAINT_Msk中断产生,从此读出数据后,UART_INTSTS_RXTOINT_Msk并未置位,而无论少一个或多一个,都是OK的!

what’s the ~!M48x的用户别偷笑,你们也有同样的问题!

查看UART_INTSTS寄存器中RXTOINT:如果TOUTIEN和RXTOIF都被置1,该位置1. 跟着看RXTOIF的描述:

当RX FIFO非空且RX FIFO无活动发生,定时溢出计数器等于TOIC时,该位置位

总和之即:超时中断要产生,需要RX FIFO非空,并且TOIC超时溢出并使能。那么问题就在于当正好到RX FIFO阈值中断时,在中断服务函数把数据全都读出来了导致RX FIFO空了,所以就不满足了,自然就无法产生超时溢出中断了!真是蛋疼的设计,那怎么解决呢?解决方法很简单,在阈值中断中让rx fifo不空就完事了。留一个字节在fifo里!问题完美解决!

顺便再吐槽一下:UART0的RX和TX FIFO是16, UART1和UART2的RX TX FIFO是64!就三个UART还整的不一样,顺便赞一下:RS485模式,使用RTS控制485的换向端,真香!

坑七:NuLink VS JLink

忍受了这么久的NULink,现在终于可以用JLink来欢快的仿真下载调试NUC505了,爽的不要不要的,实现方式很简单,就是在JLinkDevices.xml中添加上NUC505的型号就可以了,如下:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
<Device>
    <ChipInfo Vendor="Nuvoton" Name="NUC505YO13Y" WorkRAMAddr="0x20000000" WorkRAMSize="0x00020000" Core="JLINK_CORE_CORTEX_M4" Aliases="NUC505DL13Y; NUC505DS13Y"/>
    <FlashBankInfo Name="SPI Flash" BaseAddr="0x00000000" MaxSize="0x00200000" Loader="Devices/Nuvoton/NUC505_SPIFLASH.FLM" LoaderType="FLASH_ALGO_TYPE_OPEN" />
</Device>

然后从keil目录下找到NUC505_SPIFLASH.FLM拷贝到 .\SEGGER\JLink\Devices\Nuvoton目录下即可,就能成功的读到芯片的ID。剩下的跟普通的仿真调试一样了。

顺便记一下解决仿真时弹出Verification 的ERROR:

Verification of application image failed.

先看下下面的 “Download to flash” 是否√了。

checkDownloadFlash.

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-12-29,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 TopSemic嵌入式 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
React Native在美团外卖客户端的实践
美团研发团队基于React Native开源框架,并结合美团业务场景,定制化开发了一套动态化方案。本文主要分享该动态化方案在美团外卖业务场景中的实践,希望能给大家一些启发。
美团技术团队
2019/12/23
2.3K0
React Native在美团外卖客户端的实践
美团智能支付稳定性测试实战
本文介绍了美团智能支付业务在稳定性方向遇到的挑战,并重点介绍QA在稳定性测试中的一些方法与实践。
美团技术团队
2019/01/09
1.4K0
美团配送实时特征平台建设实践
导读:2019年5月,美团正式推出新品牌「美团配送」,升级配送开放平台。那你知道支撑美团配送大脑的实时特征平台是如何建设的吗?如何实现每分钟生产千万级的实时特征?如何在70w+QPS的场景下实现4个9响应耗时在50毫秒的需求?本文将为大家介绍配送实时特征平台的发展历程,关键技术和实践经验。
Houye
2021/01/27
1.5K0
美团配送实时特征平台建设实践
系统总出故障怎么办,或许你该学学稳定性建设!
说到系统稳定性,不知道大家会想起什么?我想大多数人会觉得这个词挺虚的,不知道系统稳定性指的是什么。一年前的我看到这个词,也是类似于这样的感受,大概只知道要消除单点、做好监控报警,但却并没有一个体系化的方法论。经过一段时间的摸索,我对系统稳定性有了较为体系化的认识,于是迫不及待地希望和大家一起分享。所以今天,就让我跟大家简单聊聊系统稳定性建设这个话题吧!
陈树义
2022/09/08
8340
系统总出故障怎么办,或许你该学学稳定性建设!
美团高性能终端实时日志系统建设实践
你是否经常遇到线上需要日志排查问题但迟迟联系不上用户上报日志的情况?或者是否经常陷入由于存储空间不足而导致日志写不进去的囧境?本文介绍了美团是如何从0到1搭建高性能终端实时日志系统,从此彻底解决日志丢失和写满问题的。希望能为大家带来一些帮助和启发。
美团技术团队
2022/12/16
9560
美团高性能终端实时日志系统建设实践
美团外卖自动化业务运维系统——Alfred
背景 美团外卖业务在互联网行业是非常独特的,不仅流程复杂——从用户下单、商家接单到配送员接单、交付,而且压力和流量在午、晚高峰时段非常集中。同时,外卖业务的增长非常迅猛,自2013年11月上线到最近峰
美团技术团队
2018/03/13
1.9K0
美团外卖自动化业务运维系统——Alfred
美团外卖订单中心的演进 转
美团外卖从2013年9月成交第一单以来,已走过了三个年头。期间,业务飞速发展,美团外卖由日均几单发展为日均500万单(9月11日已突破600万)的大型O2O互联网外卖服务平台。平台支持的品类也由最初外卖单品拓展为全品类。
chinotan
2019/04/03
1.1K0
美团即时物流的分布式系统架构设计
本文根据美团资深技术专家宋斌在ArchSummit架构师峰会上的演讲整理而成,主要介绍在美团即时物流分布式系统架构逐层演变的进展中,遇到的技术障碍和挑战,还有我们的解决思路。
美团技术团队
2019/01/07
1.1K0
美团点评智能支付核心交易系统的可用性实践
每个系统都有它最核心的指标。比如在收单领域:进件系统第一重要的是保证入件准确,第二重要的是保证上单效率。清结算系统第一重要的是保证准确打款,第二重要的是保证及时打款。我们负责的系统是美团点评智能支付的核心链路,承担着智能支付100%的流量,内部习惯称为核心交易。因为涉及美团点评所有线下交易商家、用户之间的资金流转,对于核心交易来说:第一重要的是稳定性,第二重要的还是稳定性。
静儿
2018/05/24
2.7K4
美团即时物流的分布式系统架构设计
美团外卖已经发展了五年,即时物流探索也经历了3年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设经验。最主要的收获包括两点:
美团技术团队
2018/11/23
1.5K0
美团即时物流的分布式系统架构设计
大神分享美团外卖订单中心演进之路
作者:何轼 来源: http://tech.meituan.com/mt_waimai_order_evolution.html 前言 美团外卖从2013年9月成交首单以来,已走过了三个年头。时期,事
小小科
2018/05/04
2.9K1
大神分享美团外卖订单中心演进之路
智能支付稳定性测试实战
美团支付承载了美团全部的交易流量,按照使用场景可以将其分为线上支付和智能支付两类业务。线上支付,支撑用户线上消费场景,处理美团所有线上交易,为团购、外卖、酒店旅游等业务线提供支付能力;智能支付,支撑用户到店消费场景,处理美团所有线下交易,通过智能POS、二维码支付、盒子支付等方式,为商家提供高效、智能化的收银解决方案。其中,智能支付作为新扩展的业务场景,去年也成为了美团增速最快的业务之一。
美团技术团队
2018/12/14
1.1K0
智能支付稳定性测试实战
美团外卖持续交付的前世今生
美团外卖自2013年创建以来,业务一直在高速发展,从早期单一的美食业务发展成为包含闪购、跑腿、闪付、营销、广告等在内的平台业务。每个业务团队虽然都有不同的业务形态,但是几乎都有相同的诉求:需求能不能尽快的上线?本文将从外卖的历史实践中,浅谈一个好的持续交付需要综合考虑哪些关键因素,希望对大家有所帮助或启发。
美团技术团队
2020/02/19
1.6K0
美团外卖持续交付的前世今生
美团即时物流的分布式系统架构设计
美团外卖已经发展了五年,即时物流探索也经历了3年多的时间,业务从零孵化到初具规模,在整个过程中积累了一些分布式高并发系统的建设经验。最主要的收获包括两点:
物流IT圈
2019/07/16
1K0
美团即时物流的分布式系统架构设计
万字详解高可用架构设计
系统高可用是一个宏大的命题,从设计思想、架构原则到工程能力、服务管理等等方方面面,每个视角单拆出来都不是一篇文章可以解决的。本文将从大局上全面系统地梳理高可用系统架构,起到一个提纲挈领的作用。
腾讯云开发者
2025/01/07
3.1K0
万字详解高可用架构设计
美团大规模微服务通信框架及治理体系OCTO核心组件开源
微服务通信框架及治理平台OCTO作为美团基础架构设施的重要组成部分,目前已广泛应用于公司技术线,稳定承载上万应用、日均支撑千亿级的调用。业务基于OCTO提供的标准化技术方案,能够轻松实现服务注册/发现、负载均衡、容错处理、降级熔断、灰度发布、调用数据可视化等服务治理功能。
美团技术团队
2019/08/15
1.2K0
美团大规模微服务通信框架及治理体系OCTO核心组件开源
全链路压测平台(Quake)在美团中的实践
在美团的价值观中,“以客户为中心”被放在一个非常重要的位置,所以我们对服务出现故障越来越不能容忍。特别是公司业务正处在高速增长的阶段,每一次故障对公司来说都是一笔不小的损失。而整个IT基础设施非常复杂,包括网络、服务器、操作系统以及应用层面都可能出现问题。在这种背景下,我们必须对服务进行一次全方位的“体检”,从而来保障美团多个业务服务的稳定性,提供优质的用户服务体验。真正通过以下技术手段,来帮助大家吃的更好,生活更好:
美团技术团队
2019/04/04
2.3K0
全链路压测平台(Quake)在美团中的实践
美团外卖广告智能算力的探索与实践(二)
总第506篇 2022年 第023篇 在深度学习时代,算力的需求和消耗日益增长,如何降低算力成本,提高算力效率,逐渐成为一个重要的新课题。智能算力旨在对流量算力进行精细化和个性化分配,从而实现系统算力约束下的业务收益最大化。 本文主要介绍了美团外卖广告智能算力从线性规划算法到进化算法的技术演进过程,给出了一种基于进化算法的多动作算力分配方案,希望能给大家带来一些帮助或者启发。 1 业务背景 2 整体思路 2.1 算力分配问题形式化描述 2.2 挑战分析 3 方案设计 3.1 全链路最优算力决策 3.2 系
美团技术团队
2022/04/29
9980
美团外卖广告智能算力的探索与实践(二)
美团外卖Android Crash治理之路
Crash率是衡量一个App好坏的重要指标之一。如果你忽略了它的存在,它就会得寸进尺,愈演愈烈,最后造成大量用户的流失,进而给公司带来无法估量的损失。本文讲述美团外卖Android客户端团队在将App的Crash率从千分之三做到万分之二过程中所做的大量实践工作,抛砖引玉,希望能够为其他团队提供一些经验和启发。
美团技术团队
2018/08/01
1.2K0
美团外卖Android Crash治理之路
高可用 兜底方案
对于秒杀系统来说,在大流量的迅猛冲击下,都曾经或多或少发生过宕机的情况。当一个系统面临持续的大流量时,它其实很难单靠自身调整来恢复状态,你必须等待流量自然下降或者人为地把流量切走才行,这无疑会严重影响用户的购物体验
BUG弄潮儿
2021/09/10
1.4K0
高可用 兜底方案
推荐阅读
相关推荐
React Native在美团外卖客户端的实践
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档