ATMEL Assembly Code Debugging

@Mahihassi

As an accomplished Electrical Engineer with a profound background in embedded systems, I wholeheartedly embrace each challenge as an opportunity to sharpen my skills and broaden my knowledge. With specific expertise in ATMEL processors and a strong affinity for debugging, I'm confident in my ability to address your current issue effectively. My experience extends not only to ARM assembly debugging but also to the entire product development workflow from system architecture and PCB design through to firmware development. While proficiency alone is valuable, I believe the true worth lies in how it is utilized and combined with problem-solving skills. This mindset is at the core of my practice, which allows me to efficiently identify and fix logical errors, ensuring a robust software solution. Beyond addressing this immediate need for code debugging, partnering with me would provide access to a broad array of skillsets. Having worked on diverse IoT projects throughout my career, I bring a unique perspective that could uncover any potential issues prior to deployment. Additionally, my comprehensive understanding of hardware and software integration can guarantee an optimized embedded solution. All things considered, choosing me would mean receiving impeccable services in not just code debugging but for the entirety of your project's needs.

@diektech

Hi, this is Elias from Miami. I read your brief and it sounds like a classic regression: a previously working feature broke right after a new feature was added, which usually points to a clobbered register, stack misuse, ISR side effects, or timing/interrupt priority changes. One quick note: ATmega128L is an AVR 8-bit MCU, so the assembly is AVR, not ARM. If the code is truly on ATmega128L, I’ll debug it as AVR (AVR Studio / Microchip Studio, avr-gdb, JTAGICE/AVR Dragon, simulator). If you actually meant an ARM-based ATmel part (like SAM series), tell me which exact chip and toolchain. My approach: * reproduce the failure with a minimal test + confirm the last known good build * diff the new feature changes to spot register/flag/stack/ISR interactions * step through the failing path, verify calling convention (saved regs, SREG, stack) * check interrupt handlers (push/pop balance), shared globals, and timing loops * patch + add small assertions/logging (UART/GPIO toggles) to prevent re-breaks Q1: Can you share the exact ATmega128L setup (clock, fuses) and which toolchain/debug method you have (JTAG, ISP-only, simulator)? Q2: Did the new feature add/modify any ISR, timers, or global variables shared with the old feature? Q3: When it “doesn’t work,” is it a full lockup, wrong output, or intermittent timing issue (and how can I reproduce it)? Regards, Elias

@juanjosec63

Hello, I’m excited about the opportunity to contribute to your project. With solid experience in low-level microcontroller development and debugging assembly code on ATMEL platforms, I can methodically analyze the interaction between the existing logic and the newly added feature to identify timing conflicts, register misuse, stack corruption, or interrupt handling issues that may be causing the failure. I’ll use a structured debugging approach with simulator tools and hardware-level tracing where needed to isolate the root cause and restore stable behavior without breaking other functionality. The goal is to deliver clean, reliable firmware that behaves predictably under all expected operating conditions. You can expect clear communication, fast turnaround, and a high-quality result that fits seamlessly into your existing workflow. Best regards, Juan

@ihorh8

Hi. How are you? I already checked your description carefully and I'm happy to bid for your project. I am an embedded software engineer with deep experience debugging low-level assembly on ATMEL AVR microcontrollers, including ATmega-class devices, and resolving feature regressions caused by timing, register, or interrupt interactions. My approach is to reproduce the fault, isolate the delta introduced by the new feature, and systematically verify register usage, stack discipline, ISR side effects, and memory/peripheral configuration using AVR Studio/Microchip Studio and on-chip debugging. I deliver clear root-cause findings, corrected assembly code, and concise documentation so the fix is robust and easy to integrate. Will wait for your quick response. Thanks. Ihor.

@Georgeoustar

Hi there, Thank you for the opportunity to submit this bid for your project. I’m genuinely interested and excited about what you’re building, and I can see real potential for it to create value for your users as well as for your business. From what I understand so far, the goals are clear, realistic, and aligned with the kind of work I enjoy doing—solving concrete problems, making things easier for people, and delivering something that looks professional and feels effortless to use. I bring a mix of technical skill, structured planning, and practical communication. That means you can expect clear milestones, transparent pricing, and straightforward updates rather than jargon. My goal is to make the process feel organized and predictable for you, while still leaving room to improve details as we learn more during the project. If we move forward, I’ll focus on making the experience smooth for you: clear expectations, no surprises, and a result that matches what we agreed at the outset. Regards, George M.