Who is responsible for creating and updating the Burn down chart?

Dejan, one of the things you should try to get used to is that neither Scrum or Agile are very prescriptive, and it is unwise to simply take what works well for others and adopt it without understanding why it is a good practice for that situation.   

You should not come to this forum looking for specific answers.   You are already working through some of your own questions around this topic.   Continue exploring what makes sense for you and your team.

A Burndown/Burnup chart helps the Scrum Team visualize where they are in the sprint, and whether the Sprint Goal (or Sprint Forecast) is on track.   What I can tell you is to consult the Scrum Guide to understand the roles that benefit from such transparency and information radiation.   This understanding should help guide your decisions on who should maintain this and when.

Shouldn’t it be done by the first person who sees that it needs doing?

Although the scrum guide does not specifically say so, my understanding is the development team is responsible for preparing and maintaining the burn-down chart.

First, I am going to agree with @Timothy Baffa and encourage you to take his advice.  Second, @Ian Mitchell has the best one line answer you will ever see for your question. Here are my answers

1. Anyone that is involved in the work and sees the burndown chart is not current and accurate.

2. This should never happen because the burndown chart is for the work being done during the Sprint by the Development Team. So why would anyone but the Development Team be responsible for updating the information?

3. As @Ian Mitchell mentions, when it needs to be done.

Burndown charts are a tool for the development team to communicate their progress. But they can also be used as weapons against a development team by individuals that do not understand their purpose or the methods of agile software development.  As you said, it can be useful but it can also be a complete waste of time if too much emphasis is put on having the "perfect" burndown.  So I caution you to be absolutely sure that the tool will be useful for everyone and not something that will be used wrong.  

Agree with Daniel Wilhite (especially the last paragraph). There must be an alignment or an understanding of why you are going to use burn down chart.

I had an experience wherein it was used as a weapon against the team that they are not doing their work simply because the chart is bad (or at least what they understand that it is bad).

Thanks for all great thoughts.

I was just wondering what are the ways for PO to track the Sprint progress toward Sprint Goal?

Since Daily Scrum in not an option, my thought was that using of Burn down (up) chart will tell PO that Dev team is on track every single day.

I was just wondering what are the ways for PO to track the Sprint progress toward Sprint Goal?

Shouldn't the Product Owner trust the Development Team to meet the Sprint Goal, and to track progress themselves? If the Goal appears to be under threat, wouldn't Scrum Team members collaborate to resolve it?

Sure. Thanks

One thing about Scrum is that it requires a lot of trust and a measure of hope.  As @Ian Mitchell said the PO will have to trust the Development Team to raise issues or potential problems if they feel it will impact the Sprint Goal in any way, either negative or positive. In the end no one is going to consciously do anything that will impact the team's ability to deliver value to the stakeholder. 

Let me ask some other questions that might help put some things into perspective.  How does the Development Team know that the items in the Product Backlog are ordered in a manner that ensures they will be doing the right things in the right order? How do the stakeholders know that the Scrum Team will be working on solving the problem that they are facing?  There is a lot of trust involved.  Open and honest communication is required without fear of retribution or blame being placed. As the Scrum Guide states in the opening sentence of the section on the Scrum Values:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. 

If it helps any, I suggest visualizing the Scrum Team without hierarchy. Scrum Master, Product Owner, and Development Team share the same goals and perform their roles for the collaborative, horizontally not vertically. The Product Owner is not a Management role for this purpose and so there's nothing for them to 'track' since the Dev team is accountable for the Sprint Backlog and their ability to complete the Sprint Goal. This ownership requires them to collaborate and communicate with the Product Owner anytime they need to.

In that light, the burndown tool could be useful to show specific progress in the Sprint rather than all the items in the Sprint. For example, limit it to Sprint Goal related work if the team is not 100% focused to the Sprint Goal and has items in the Sprint for existing product support/maintenance, dependency work, service desk, etc.

The benefit I've seen come from Burndowns is to help identify the impact of work that isn't visualized in the Sprint (hidden work, external requests, distractions etc.). Once team is able to have all work captured in the Sprint, the Daily Scrum typically ends up removing the need for the tool. 

Since Daily Scrum in not an option,

Dejan, why don't you believe the Daily Scrum is an option for the PO to assess Development Team progress towards meeting the Sprint Goal?

I reckon the statement from the Scrum Guide "As work is performed or completed, the estimated remaining work is updated" indicates that the Burn Down chart may be the responsibility of the Development Team and the Daily Scrum gives the opportunity for them to update this chart on a daily basis. 

Another statement from the Scrum Guide that I believe supports my inference in my previous post is "The Development Team tracks the total work remaining at least every daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress." 

Hi @Dejan Majkic - All current-age agile project management tools (Jira etc.) come up with automatic Sprint Burndown/ Burnup charts on a daily basis, so the Scrum Team are not required to create/ update it by their own.

However, if that is not the option, I'll go with the suggestions already provided by the distinguished fellows. The only thing to be added from my side is - the Scrum Master can choose to ensure that the Burndown/ Burnup charts are being updated regularly (per the frequency decided by the Scrum Team) but the ultimate responsibility lies with the Development Team itself.